Beware the IDE: The Risks of Standardizing on One IDE

[article]

Given the benefits of IDEs, the fact that different tools have different advantages and disadvantages, and the desire to control the divergence of IDE and build configuration, many teams want to standardize a single IDE. Standardizing on development environments raises some interesting challenges. Moving beyond the simple features that an IDE provides, individual productivity is closely related to how team members adapt tools to individual styles. IDEs allow developers who are skilled in the uses of a particular tool to learn how it works and to customize the tool to fit their work style. For all of the benefits of customizations, differences in configuration can make it more difficult for another individual to contribute to the same code. The temptation is to simplify the problem by standards. Since there are other standard tools on your project, question if would it make sense to add IDEs to the list.

One IDE for All?
When considering development tools and processes, standardization often enables simplification. Some tools address the constraints of the problem that the team is working on. The set of languages and version of compilers, for example, may be defined by the target environment. Some tool standards constrain the problems that a team needs to solve. Since no tool is perfect for all situations, a standard build tool set means that you can fix a problem once and have consistent results for all team members.

Sometimes a tool standard comes out of simplicity. Picking Maven as your build tool for a Java project gives you a certain degree of integration between build scripts and IDEs. And having a standard compiler and build toolset give you a definition for working software that works in the integration build when you use these tools.  SCM patterns, such as private build and integration build, are based on being able to reproduce, with a reasonable degree of fidelity, an integration build in a developer workspace.

Some standards, such coding standards, don't have a large degree of impact on how a developer works, assuming that there is a mechanical way to apply them.

Once the team agrees to standards, they can be configured in an IDE and someone writing code can decide how an algorithm should work rather than where the opening brace for a method call goes. Build tool and coding style standards simply define end points in an executable way (i.e., tests).  It's possible to set up your surrounding tools in a way such that developers can work in whatever way is most effective, as long as their code passes these tests.

IDEs are a bit different. Having a standard IDE simplifies the problem of deciding what tool a novice developer on the team should use. When in doubt, just use the standard one.

But what about the people on the team who are expert in a particular tool? If the point of an IDE is to improve productivity, forcing such a standard on everyone can result in a decline of productivity if someone has expertise with the other tool. Often, when one switches between, say, Eclipse and Idea, there is a period of time where it was difficult to work in either tool because of subtle differences in approach. This is surmountable, and learning a new tool is a useful experience, but it does have a cost.

Adding to the complexity of IDE selection is that IDEs have a variety of strengths and weaknesses. Even if you use Eclipse for most of your work, you may find that the GUI builder in NetBeans is so good that you might want to use NetBeans for part of your swing development, or the profiler in NetBeans, if that works well for you. Requiring a standard IDE for all work would remove that option.
If developers are considered experts in their craft, why impose a tool that affects something as basic as how a developer works with her code on a minute to minute basis. In other professions, experts use tools that they are the most comfortable with. Musicians are fussy about not using an instrument other than their own. Even musicians who play less portable instruments, bass, piano, will go to great lengths to attempt to use their instrument or one similar. Why expect less of developers?

Tags: 

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 Techwell.com,  and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.

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 steve@berczuk.com or visit berczuk.com and follow his blog at blog.berczuk.com.

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, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!