Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


10 Reasons to Dump Your Java IDE : Page 2

Is it possible that the very thing that is supposed to facilitate faster Java coding is in fact, an unseen liability, crippling development flexibility and team contribution? Guest columnist Brad O'Hearne says the sooner you dump your IDE, the better off you'll be.




Application Security Testing: An Integral Part of DevOps

No. 5: Team development compatibility
I 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.

Brad O'Hearne is an independent developer, Java instructor, and Sun Certified Java Programmer, with extensive enterprise and Web development experience, located in Irvine, CA. You can reach him at brado@neurofire.com
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.
Thanks for your registration, follow us on our social networks to keep up-to-date