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.