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).
|
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.
No. 5: Team development compatibilityI have found that IDE automation actually causes more problems in the team environment than it solves. An IDE takes the effort out of performing certain tasks, such as compiling, generating Jar files, generating RMI stubs, etc. Such automation is convenient in isolation, but not on a development team, where team members must interoperate regularly, both in terms of source code control and the build process. The development environment(s) used need to be completely transparent to these two processes and must not impede the efficiency and success of those processes.
I have been on projects in which part of the team used IDEs, and part of the team used editors, and the IDE contingent would repeatedly have to manipulate the IDE to work properly when a build or source control process was changed. The text-editor contingent had no such problems. They ended up supporting the IDE, in addition to their own development processes.
No. 6: Better understanding of the team development technology
In addition to being compatible with a team, it is important to have a thorough understanding of the technology used by the team. Thorough knowledge of source code control and build environments is key to understanding integration and addressing problemswithout bringing the whole team to a grinding halt when a hiccup occurs. A dedicated configuration management engineer is not always available, and it behooves team members to be familiar with the process. In my experience, heavy IDE users more often do not understand these systems, because IDE automation provides thorough insulation. Since I switched to Emacs, I have had regular, intimate contact with these systems (in fact, I recently got stuck with the task of rewriting our build, due to my newfound expertise).
No. 7: Cross-platform compatibility
Typically, IDEs are developed for specific platforms. Expanding to other platforms (if even possible, and quite frequently, it isn’t) comes with a price tag. Emacs for Linux, Unix, Mac, and Windows are once again available free, and it is wonderful to have a consistent interface across platforms.
No. 8: Cross-language compatibility
Many Java developers, like me, develop in other languages too. Very few IDEs, however, support multiple languages. So, for example, if I want to develop in both Java and C++, both at work and at home, I am in the position of needing to purchase four software licenses (home and work licenses for both the Java and C++ IDEs). A developer can use Emacs across languages, with no training overhead. Maximum productivity is achieved by focusing on development, and not the IDE.
No. 9: More doesn’t always mean more
Although IDEs offer convenient integration with third-party applications, such as source code control tools, such integration is often limited. Often the third-party integration doesn’t include all of the third-party tool’s features. So what is supposed to represent an additional level of automation is actually less functionality than the third-party tool offered on its own.
Worse, sometimes third-party integration is not an added bonus: it exists as a workaround to make up for the fact that the IDE doesn’t play nice with the third-party tool outside of the IDE. The IDE I used managed its projects in such as way that it was difficult to use a third-party source code control product outside of the IDE, so such integration wasn’t an added bonus, it was an added necessity. “Full” integration and support of these tools are often gradually added to the IDE in order to drive up product upgrade purchases.
After I dumped my IDE, I realized how foolish I had been to box myself into a situation where I was actively petitioning the vendor to bill me again for added support for freely available tools, and for features that mandated full integration only because the product would not work with third-party software otherwise. Once again, Emacs has no such troubles. I have a full range of functionality in CVS, make, or Ant (the source code and build systems I currently use).
No. 10: Avoid the learning curve
It is a fallacy that IDEs make things easier by definition. I was up and running with Emacs in 20 minutes, and within an hour or two I had mastered everything I needed in order to start developing. I can’t say the same for IDEs. By nature, automation insulates the developer from what’s under the hood, and IDEs typically produce project artifacts: some hierarchical directory structure and/or configuration files that must be in place to use the code in the project.
I have witnessed projects where significant time was wasted repairing IDE projects when the configuration files became corrupted, because the developers did not understand the underlying structure of the project the IDE maintained. Emacs deals with text; no hidden artifacts, no surprises, and no project corruption.
Don’t get me wrong, I am not saying that an IDE can never be justified. I am saying that anyone would be hard-pressed to create a general justification for using one. No matter if you look at it from a personal standpoint or a corporate one, from a financial perspective or production-oriented, I believe that text-editors have IDEs beat hands-down.
Consider me your guinea-pig. I’m going on five months now, and I wouldn’t consider returning to an IDE. And, as an added bonus, I found a New Year’s resolution I can keep.
