Beware the IDE: The Risks of Standardizing on One IDE

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 IDE 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 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 are 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 developers 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, and IDEs also support this goal.

IDEs help 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 -- enabling 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--, and working with other, supporting tools such as SCM and Issue Tracking systems via plugin mechanisms. IDEs also allow you code without thinking too much about coding style conventions. A properly configured IDE can either format the code as you type, or it can let you format it after. You need not worry about tabs or spaces or alignment, or other peripheral tasks. This allows you maintain focus and avoid changing contexts to perform your primary tasks.

IDEs improve feedback, identifying errors in your code as you type,  avoiding the interruption in flow that a full compile/build/test cycle can cause.  While a full compile build test cycle will give you an accurate assessment of the state of your 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 your integration environment and which you use to deliver the application, and there are risks lurking in these differences. If your IDE uses