Beware the IDE: The Risks of Standardizing on One IDE


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) should consider the ability to synchronize between IDEs and scripts to be a high priority as IDEs and other build tools serve complimentary purposes, and are of the most value when their configurations match as much as possible.

You can benefit by versioning configurations relating to style that can be universally used by all team members. It’s important to keep the build scripts as the source of build and dependency configuration as much as you can.

Bridging The Gap between IDE and Build Tools
The private build pattern gives the most concise guidance for how to ensure that a build is sync: run a build in your workspace with the same toolset that works in the integration build. A continuous integration process (running the integration build patterns) provides a backstop for when you goof. Incremental builds are fine in an IDE when you are coding, and the instant compilation that occurs after a change helps to maintain flow when coding. There can be subtle, and not so subtle, differences on the build environments, though, that range from specific compiler implementations to path configurations.  This means that what works in your IDE may not work in your build and broken builds slow everyone down

As long as the contract of the integration build being successful is honored, we should not need to overly constrain how developers work.
What To Do?
IDEs are a common part of a developer's tool kit. They are highly customizable, increase productivity, and help enforce coding standards. Some developers have very strong opinions about what the best one is. Every team struggles with development standards. Standards affect communication (coding standards) and execution (tool standards). Standards can help a team be more effective by eliminating discussion on matters that are less important to the end result and also by enhancing communication by establishing a common style and language.

Too many standards, or standards applied to appropriate concepts can have the effect, reduce productivity and cause the team to spend a disproportionate time coding to the standard, rather than delivering value. Let's wrap up by offering some recommendations on the questions we raised at the start of this article.  We recommend:

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!