Beware the IDE: The Risks of Standardizing on One IDE


Two topics that are likely to launch a development team into an impassioned discussion are development standards and development environments (IDEs, editors, etc). Combining the two topics into that of standardizing on development environments, is even more likely to spark debate. Decisions about development tools affect the day to day workings of each person on the team as well as the productivity of the team, and as such are important to discuss as a team organizes itself.


When making these decisions, it's important to consider the reasons for standardizing, how much you need to standardize, and how to balance productivity in an Interactive Development  Environments (IDEs) with accuracy in a build. There are three questions that a person who is concerned with configuration management issues needs to address when considering how IDEs fit into the development ecosystem:

•    Does the team need to standardize on a specific IDE (if any) and related tool set?
•    What, if any, IDE configuration artifacts should be placed under version management?
•    What is the balance between the goals of a productive development environment the requirements of the integration and production environment?

This article will make some suggestions to help your team answer these questions and be more productive as a team and as individuals.

Development Environments (Interactive and Not)
There are many productive ways that developers work, ranging from a simple text editor plus command line combination (NotePad in Windows being one example), to highly customizable editing environments (emacs with JDEE ), to standalone Integrated Development Environment (Eclipse , IDEA , NetBeans ). Developers in any of these camps can either work with whatever comes out of the box or with environments highly customized to their work style. We know developers who have personal emacs configuration files that have been maintained and moved from project to project for years, and also developers who switch between IDEA and Eclipse at will.

A discussion on tool standardization applies to both text-editor- based environments and IDEs. We'll focus the discussion on IDEs, as IDEs are typically more feature-rich and more likely to involve external configuration. The key question of how a development environment affects team and individual productivity remain the same.

Productivity and IDEs
IDEs can increase productivity for individual developers by enabling them to maintain Flow. Flow is a hyper-productive mental state where a person is fully immersed in what they are doing. Agile development practices support flow by working to eliminate non-productive work and to focus the team on tasks that add value.  IDEs also support this goal.
They help to maintain flow by allowing developers to focus on the intent of their development level tasks rather than mechanics, giving the developer more rapid feedback on the results of tasks such as refactoring .  This enables a developer to perform refactorings, such as move method, by indicating what code the change will affect, rather than having to perform the mechanical copy, paste, and the search for compile errors elsewhere in a project.  It also eliminates the need to work with other supporting tools, such as SCM and Issue Tracking systems via plugin mechanisms.

IDEs also allow code without thinking too much about coding style conventions. A properly configured IDE can either format the code as it’s typed or can format it after. There’s no need to worry about tabs, spaces, alignment, or other peripheral tasks. This helps to maintain focus and avoid changing contexts to perform primary tasks.

IDEs improve feedback, identify errors in your code as it’s typed,  and also avoids the interruption in flow that a full compile/build/test cycle can cause. 

While a full compile build test cycle will provide an accurate assessment of the state of an application, if it takes longer than a few seconds, it will interrupt your thinking. To allow for a more rapid incremental build compile and run scenario the IDE environment is not always exactly the same as the full build process that runs in an integration environment that is used to deliver the application. There are risks lurking in these differences. If an IDE uses a build configuration that is different from the one used in the integration build, they must be kept in sync. One must also be careful to avoid the "works in my IDE but not in the integration build" scenario, by running a private build in your workspace before committing changes.


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!