configuration that is different from the one used in the integration build, they must be kept in sync. One must also 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 a single IDE. Standardizing on development environments raises some interesting challenges. Moving beyond the simple features that an IDE provides, 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 to customize the tool to fit their work style. For all of 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, question if would it make sense to add IDEs to the list.
One IDE for All?
When considering development tools and processes, standardization often enables simplification. Some tools address the constraints of the problem that the team is working on. The set of languages and version of compilers, for example, may be 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. And having a standard compiler and build toolset give you a definition for working software that works in the integration build when you use these tools. 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, such 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 agrees to standards, they can be configured in an IDE and someone writing code can decide 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 (i.e., tests). 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 if someone has expertise with the other tool. Often, when one switches between, say, Eclipse and Idea, there is a period of time where it was difficult to work in either tool because of subtle differences in approach. This is surmountable, and learning a new tool is a useful experience, but it does have a cost.
Adding to the