Beware the IDE: The Risks of Standardizing on One IDE


•    Allow team members to work with whatever development environment toolset that is most productive for them, given the constraints of the project.
•    Define your workspace set up process in terms of the least common demominator: getting the files on disk using command line tools for example. This will help establish consistency with the Integration Build environment.
•    Focus on defining end results, not mechanisms. If indentation is important, specify the rules, not the IDE. Recommendations are fine, but if someone is more productive with a different toolset than the recommended one, it should be fine.
•    If something is really important, add it to the build. There are plugins that will run style checks (both cosmetic and functional) at build time, generating warnings or failing the build if something is amiss. The integration build is the one point in the process where a consistent environment is guaranteed, so it’s good to use as a gate.
•    Version only primary artifacts and use tools to generate secondary ones, such as build settings for an IDE, where feasible. Primary artifacts include build files, but not IDE configuration files relating to build settings. If the IDE has the ability to version style related artifacts independently of the project configurations, these should be treated as versioned artifacts.

The measure of whether the toolset works is whether the code meets the standards set by the build and also whether those using other tools can work easily with the code. Don't require a specific IDE tool set as long as the core development standards can be supported by the developer’s tool of choice.

Vendors should consider the individual and team aspects of IDEs and ensure that personal SCM tool settings are not checked in, for example, to make this possible.
The question of tools and standards can be controversial. The simplest solution that balances team, individual joy, and productivity is to focus on whether the standard leads to more customer value.  Also, define standards in terms success criteria.  For example, how quick is it to set up a workspace and features of the code, rather than mechanisms? There is a difference between consistency in important things, which is valuable, and conformity, which is often mistaken for consistency. Focus on delivering consistent results and respect that a team will know how to get there.


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!