Beware the IDE: The Risks of Standardizing on One IDE

learning a new tool is a useful experience, but it has a cost.

Adding to the complexity of IDE selection is that IDEs have a variety of strengths and weaknesses. Even if you use Eclipse for most of your work, you may find that the GUI builder in NetBeans is so good that you might want to use NetBeans for part of your Swing Development, or the profiler in NetBeans if that works well for you. Requiring a standard IDE for all work would cut you out of that option.

If developers are considered experts in their craft, why impose a tool that affects something as basic as how a developer works with her code on a minute to minute basis. In other professions, experts use tools that they are the most comfortable with. Musicians are fussy about not using an instrument other than their own. Even musicians who play less portable instruments, Bass, Piano, will go to great lengths to attempt to use their instrument, or one similar. Why expect less of developers? If someone is hyper-productive on IDEA, what is the benefit of having them context switch to Eclipse?  In Pragmatic Thinking and Learning , Andy Hunt comments about the difference between experts and novices as it related to standards and tools: Novices don't really care, and having a standard helps. Experts know their tools well. While a novice can select the refactor->move method context menu, an expert in IDEA will enter the shortcut (F6) getting to the interesting work more quickly. The same IDEA expert will still know to refactor a method if they are using another tool. It will just be more slow.

When trying to decide what tool is best we're often inclined to confuse "familiar" with "better."  It's in the interests of everyone on the team to be cautious of this tendency.

Closely related to standard IDEs is the question of how quickly and reliably one can set up a new environment. Organizing your setup around a standard IDE seems simplest, as you can version the IDE settings, but that isn't always the best approach as we'll discuss next.

The Build's the Thing
Regardless of whether or not the members of your team use one or many IDEs, Integrated Development Environments and their configurations are not identical to the build scripts that teams use to run their integration builds. In Java environments, classpaths may differ, working directories for the IDE may be different than the build environment's defaults. In some cases, differences in the compiler mechanism may lead to different results that differ from the build. These differences are OK as long as you understand them, and treat the build script as the canonical definition of "it works."

How, you ask, do you reconcile the requirements that you be able to create (IDE) workspaces quickly and also maintain the fidelity of the build? There are a few approaches. The simplest one is to maintain two sets of configuration files. The build, and the IDE configuration. Maybe you have one person who maintains the IDE settings, (perhaps one for each IDE) and keeps the files in synch if there is an issue. This means duplication, and manual work. Fans of lean software development will see duplication as waste. Fans of any process will see a manual step as a place where errors can creep in.

Another, better, way is to generate the IDE build related settings from the build files, and not version the build files (with one exception). Many modern Java IDEs for example, can use generate their configurations from Maven or Ant build