Beware the IDE: The Risks of Standardizing on One IDE

maintain IDE files is rarely high value. Maven provides tools to generate Idea and Eclipse configurations from POM files. Idea and Eclipse both have plugins that can work off of maven pom files to synchronize build and IDE settings.

Tool vendors (both IDEs and script based tools) should consider the ability to synchronize between IDEs and scripts to be a high priority as IDEs and other build tools serve complimentary purposes, and are of the most value when their configurations match as much as possible.

You can benefit by versioning configurations relating to style which can be universally used by all team members. But keep the build scripts the source of build and dependency configuration as much as you can.

Bridging The Gap between IDE and Build Tools
The Private Build pattern gives the most concise guidance for how to ensure that a build is synch: Run a build in your workspace with the same toolset that works in the Integration Build. And a Continuous Integration process, running the Integration Build Patterns, provides a backstop for when you goof. Incremental builds are fine in an IDE when you are coding, and the instant compliation that occurs after a change helps you to maintain flow when you code. But there can be subtle, and not so subtle, differences on the build environments, from the specific compiler implementation, to path configurations, that mean that what works in your IDE may not work in your build. And Broken Builds slow everyone down

As long as the contract of the integration build being successful is honored, we should not need to overly constrain how developers work.

What to Do?
Interactive Development Environments (IDEs) are a common part of a developer's tool kit. IDEs are highly customizable, and increase productivity, and help enforce coding standards. Some developers have very strong opinions about what the best one is. Every team struggles with development standards. Standards affect communication (coding standards) and execution (tool standards). Standards can help a team be more effective by eliminating discussion on matters that are less important to the end result, and by enhancing communication by establishing a common style and language. Too many standards, or standards applied to appropriate concepts can have the effect, reducing productivity and causing the team to spend a disproportionate time coding to the standard rather than delivering value. Let's wrap up by offering some recommendations on the questions we raised at the start of this article.

We Recommend:

• 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.

• Much like we would suggest for other requirements, 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 you are guaranteed a consistent environment, so use it 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 includes build files, but not IDE configuration