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

About the author

About the author

AgileConnection is a TechWell community.

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