Beware the IDE: The Risks of Standardizing on One IDE


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 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.

About the author

Brad Appleton's picture Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the book Software Configuration Management Patterns, a columnist for the CMCrossroads and AgileConnection communities at,  and a former section editor for The C++ Report. You can read Brad's blog at

About the author

Steve Berczuk's picture Steve Berczuk

Steve Berczuk is a Principal Engineer and Scrum Master at Fitbit. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at or visit and follow his blog at

About the author

Robert Cowham's picture Robert Cowham

Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!