Beware the IDE: The Risks of Standardizing on One IDE

a build configuration that is different from the one used in the Integration Build, you need to work to keep them in synch. You also need to be careful to avoid the "works in my IDE but not in the Integration Build" scenario, by running a Private Build in your workspace before committing changes.

Given the benefits of IDEs,  the fact that different tools have different advantages and disadvantages, and the desire to control the divergence of IDE and build configuration, many teams want to standardize on a single IDE. Standardizing on Development Environments raises some interesting challenges. Moving beyond the simple features that an IDE provides a team, individual productivity is closely related to how team members adapt tools to individual styles.  IDEs  allow developers who are skilled in the uses of a particular tool to learn how it works, and customize the tool to fit their work style.

For all the benefits of customizations, differences in configuration can make it more difficult for another individual to contribute to the same code. The temptation is to simplify the problem by standards. Since there are other standard tools on your project, would it make sense to add IDEs to list?

One IDE for All?
When considering development tools and processes, standardization often enables simplification. Some tools adress the constraints of the problem the team is working on. The set of languages and version of compilers, for example, may defined by the target environment. Some tool standards constrain the problems that a team needs to solve. Since no tool is perfect for all situations, a standard build tool set means that you can fix a problem once and have consistent results for all team members. Sometimes a tool standard comes out of simplicity. Picking Maven as your build tool for a Java project gives you a certain degree of integration between build scripts and IDEs that, say, Make may not. And having a standard compiler and build toolset give you a definition for "working software" which is "works in the integration build when you use these tools.  The SCM Patterns, such as Private Build and Integration Build are based on being able to reproduce, with a reasonable degree of fidelity, an integration build in a developer workspace.

Some standards, like coding standards, don't have a large degree of impact on how a developer works, assuming that there is a mechanical way to apply them. Once the team agreed to standards they can be configured in an IDE and someone writing code can spend energy deciding how an algorithm should work rather than where the opening brace for a method call goes. Build tool and coding style standards simply define end points in an executable way (ie, tests) and it's possible to set up your surrounding tools in a way such that developers can work in whatever way is most effective, as long as their code passes these tests.

IDEs are a bit different. Having a standard IDE simplifies the problem of deciding what tool a novice developer on the team should use. When in doubt,  just use the standard one. But what about the people on the team who are expert in a particular tool? If the point of an IDE is to improve productivity, forcing such a standard on everyone can result in a decline of productivity for someone who is an expert in the other tool. Often, when one switches between, say, Eclipse and Idea, there  a period of time where it was difficult to work in either tool because of subtle differences in approach. This is surmountable, and