t the opening of this year, while the rest of the world was swearing off high-fat foods and cigarettes, I was making a far different kind of New Year's resolution. I was swearing off automation.

For several years, I had used an award-winning, best-of-breed, commercial Java IDEspecifically, Borland's JBuilder versions 3.x-5.x. It was (and still is) a fine IDE, and I had become very skilled coding with it. However, rising license costs, repeated frustrations using it in a team development environment, and only partial third-party tool integration caused me to reconsider whether use of it was wise.

I wanted to talk with other developers about these ideas and so I turned to a few favorite mailing lists and began a couple of threads debating the usefulness of IDEs. Responses were spirited and quite polarized between IDE advocacy and IDE rejection. Advocates almost universally cited an increased speed of development, while opponents cited some of the reasons stated in this article. But my distinctive impression was that few had really stopped to consider the reasons why they were using the IDE they were (or not).

For those interested in adding IDE-like capability to Emacs, Brad recommends Java Development Environment for Emacs (JDEE)

After giving the IDEs and their alternatives much thought, I finally concluded that using an IDE is a shortsighted endeavor. In the end, I opted for a text editor. I chose GNU's Emacs, although which text editor you choose is not so important as the decision to use a text editor in the first place; there are others out therevi, vim, etc.that satisfy the same criteria. What is important is that this reversion to lesser technology makes a more knowledgeable, flexible, and what I believe to be an overall more valuable developer.

What follows are 10 reasons why nearly every developer should take the same leap I did and dump their IDE in favor of a text editor:

No. 1: Eliminate IDE dependence When a developer's productivity becomes tied to a certain IDE (and more specifically, the shortcuts within it), it is a serious liability. A shift in corporate standards from one tool to another or a job change can precipitously drop a developer's productivity and market value overnight. By using Emacs I am not building a dependency on any IDE's specific features, and I can use it in any company's environment, without requiring the company to commit to fees for licenses or support.

No. 2: Lower cost
Many IDEs (especially the best-of-breed class) have high licensing fees. This cost is unnecessary and compounded by the cost of support contracts and upgrades. Though a business may outfit a developer with its preferred IDE, for most of us development is more than just the yoke we pull at work. I frequently develop at home on personal projects, and I expect to use the same toolset at work and at home because of the added efficiency it affords. But the more costly an IDE, the more likely a developer will not be able to afford a personal license, and that forces a divergence between the home and work toolsets.

Likewise, a job change may find a developer at an organization that is less willing to fork out the cash for an expensive IDE. Even within an organization, there is no guarantee that the IDE the company endorses now will remain the standard indefinitely. Expensive IDE licenses are easy targets for cost-cutting, especially during lean economic times. Emacs is completely free; support is available on-line, and there is no cost to upgrade.

No. 3: Minimize impact on performance and system resources
This may seem an odd statement to make in reference to a text editor, but that is kind of the point. Simple text editors don't have significant performance or system resource issues. They are not slow to startup, shutdown, or compile, nor do they consume a significant memory footprint. The IDE I was using held a footprint of around 65MB. If a developer needs to run other memory-intensive applications concurrently, associated hardware costs increaseat work and, potentially, at home. Emacs runs just fine on almost any hardware.

No. 4: Better knowledge of Java technology
A great IDE can make a developer lazy. IDE automation is great sometimes, when you need a shortcut, but code generation and wizards create an abstraction from certain usage and specification issues. Developers need to understand Java specifications in detail before taking shortcuts. IDEs enforce the opposite principle.

Time and time again, I have seen developers fumble helplessly outside of their code-generating IDE because they don't understand the fundamental nature of the specification they are working with. With Emacs, I either know the Java specifications I need to develop, or I have to learn them.