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 remove 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?
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) in order to get 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 take more time.
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 easiest, as the IDE settings can be versioned, 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, and 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 vary from the build. These differences are acceptable, as long as they are understood 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. Perhaps one person maintains the IDE settings and another for each IDE, then the files are kept in sync 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 files.
There are also Maven plugins to generate IDE configurations from Maven build files. Keep the build files as a primary artifact and generate the derived artifact that is the IDE configuration.
The nature of how teams work with IDEs