Beware the IDE: The Risks of Standardizing on One IDE


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?

About the author

About the author

About the author

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.