Beware the IDE: The Risks of Standardizing on One IDE

files. And there are 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 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, so being able to have similar environments may more important than in other environments.  An agile Team using Pair Programming could potentially benefit most from a common tool set. So 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, and 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 their build scripts (pom.xml files if they are using Maven, build.xml if ANT, Makefiles, etc) under version management. In the interests of efficiency, you might suggest 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, and 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 to build scripts, if the IDE files are not maintained to be in snch with the build scripts, team members will learn to ignore the project files in version control. You want to avoid 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, that related to build path issues.  Use tools to keep IDE settings in synch with the build scripts.  Avoid any duplication. It may seem like a small amount of work, but  manual effort to