Scott Leberknight's Weblog

I love IDEs. They make developing software much more enjoyable and productive. But how much work do you let your IDE do? At what point are you fighting the IDE instead of being productive? Every IDE and tool you'll ever use will have some things you wish it would do or do differently. But there are certain things that I am not willing to let my IDE do for me. I think probably the most important thing is builds. Certainly in Java the de facto build tool for all sorts of Java applications is Apache Ant, but every single IDE out there has its own internal build tool and process. Most times you end up clicking through more than a few screens to configure it just right, and then find out it is really difficult or impossible to share all those settings or to easily view what the build process and settings actually are! Even worse, once you've got your IDE's build process mastered, you find you are locked into that IDE. So there is no way to share your build process with other team members who are not using the same IDE as you are.

Many organizations "solve" this problem by mandating the same IDE for all developers. I won't get into that argument, but I'll just say that I think there are positives and negatives to that approach. So, back to the build problem. Assuming all developers have the same IDE, is it a good idea to use their build configuration? I don't think so because the IDE build process is typically neither flexible nor transparent. Once you get beyond simple applications and into the arena where your build must be able to target multiple environments (e.g. development, test, production, etc.), IDE build processes quickly break down.

A simple but very relevant example is Ant's <filterset>, which I use all the time to replace tokens for different build environments among other things. To illustrate, most teams provide local instances of a database for each developer, one or more test databases where integration testing and user testing occurs, and a production database. Each of these databases is probably going to have a different URL, username, password, etc. Using the Ant <filterset> you can very easily replace tokens during the build with specific values for the target environment. Ant makes this very, very easy. You could simply place the varying properties in different properties files, e.g. dev.properties, test.properties, and prod.properties, and then use a -D property to determine which environment to build, e.g. ant -Dbuild.env=test would build the application for the test environment. Whereas this is very simple in Ant, IDEs I've used don't provide this type of customization. Why not? It seems very narrow for an IDE to assume there is only one target deployment environment.

There are other things I don't want my IDE doing for me as well, but there are of course a ton of things I really want my IDE to do for me, like code generation of getters and setters, refactoring, and being able to run unit tests within the IDE while I'm developing to get a really fast build, test, build iterative cycle going. Mainly those are things that are similar among IDEs but might have a different menu command or keystroke. IntelliJ, Eclipse, and JBuilder all can generate my getters and setters for me just fine, so what is the differentiator between IDEs? I think for me it is to what extent the IDE helps me versus hinders me, and what things it does that automate things I do all the time. I can be productive in any of those three aforementioned IDEs, but I prefer IntelliJ because it seems like it is more of an extension of me than a tool I am using. It just feels "smooth". But still, I won't let even IntelliJ do my builds for me!

There are some other relatively minor things I might avoid relying on an IDE for, but overall builds seem to be the most important aspect of development to keep out of your IDE's reach, regardless of whether you are developing in Java or something else.