may lead toward workspace configurations and configuration approaches that differ from those that make the most sense in a production environment. One useful aspect of IDEs is that they are customizable to fit the working style of the person using them. In many cases, individual customizations are not suitable for everyone on the team, but that may not matter.
Performance, Individuality, and Agility
In agile teams, people tend to work more collaboratively, in shared physical spaces, and in tighter cycles than on a traditional project. Having similar environments may be more important than in other environments. An Agile team using pair programming could potentially benefit most from a common tool set. A natural question in the context of Agile teams is whether pair programming requires that the team standardize on tool set. If any environment would require standardization, pair programming would, as there are many perceived efficiencies in moving between developers' workstations, as if they were identical environments.
While in practice, some pair-programming teams do standardize on IDEs, many others don't require a single IDE. If you are following the Driver/Navigator model for pair programming, you use whatever IDE the driver prefers. The second half of the pair will quickly pick up enough of how the IDE works to perform basic tasks. Even if you are trading the keyboard freely, the differences between environments still allows for basic collaboration and the diversity of IDEs provides a chance for team members to learn about other tools and provides a path for learning and improvement. This raises a basic question about the tradeoffs between delivering value quickly as a team and allowing individuals to work in the way that is best for them. Agile methods value individuals, so it stands to reason that, unless there is a very good reason for mandating a tool over one which a productive team member sees a strong advantage, one should allow for flexibility.
What to Version?
Everyone reading this, we hope, has build scripts (pom.xml files if they are using Maven, build.xml if ANT, Makefiles, etc.) under version management. In the interests of efficiency, it might be suggested that IDE configurations should also be under version management. To see if this makes sense, let's think about the different types of IDE configurations: build settings and tool settings.
Build settings are, in effect, what is in the build configuration files. maintaining these for IDEs is duplication. It's better to generate them from the build. Tool settings are a reasonable thing to maintain and version if there exists the possibility for user customization of settings that don't really matter to the whole team, but which improve developer productivity. Since IDE files are often redundant in building scripts, if the IDE files are not maintained to be in sync with the build scripts, team members will learn to ignore the project files in version control. It’s good to avoid a a situation where team members ignore versioned files because they don't want their files overwritten. This defeats the purpose of versioning the files and leads to confusion. Versioned files should add value to the project.
Don't version IDE configurations, as this is related to build path issues. Use tools to keep IDE settings in sync with the build scripts and avoid any duplication. It may seem like a small amount of work, but manual effort to maintain IDE files is rarely high value. Maven provides tools to generate Idea and Eclipse configurations from POM files. Idea and Eclipse both have plugins that can work off of Maven pom files to synchronize build and IDE settings.
Tool vendors (both IDEs and script-based tools)