Development teams are not static. Team members arrive and depart as the workload changes, staff quit, get reassigned or promoted or die in terrible hunting accidents. Whenever a new team member starts there is overhead before they can become productive. A large part of this is the familiarisation with the problem domain and solution under development. One element of it that is often overlooked is the effort required to establish a working development environment for the new developer.

Setting up a development environment includes more than just providing a suitable machine (preferrably not hand me down junk no one else will use). The machine will need suitable development tools, ideally these will be part of your SOE and will arrive pre-installed by IT. For many projects this will not be directly controllable, so let's assume that the new team member has just arrived and is sitting in front of a shiny new machine with the standard development tools installed. What remains to be done to get them a working development environment?

A working development environment is one in which a developer can obtain the code and compile and run it. This is not to say it necessarily will compile and run, an environment doesn't cease to be considered working if someone breaks the build or introduces a fatal bug into the code. What it implies is that all the necessary prerequisites are available and appropriately configured such that code may be compile and run absent any transient errors with the codebase.

For trivial projects with no dependencies the components installed with the SOE may be sufficient, but for projects of any significant size there are likely to be multiple dependencies not included in the SOE. This can include:

• Databases (both a DBMS and the relevant database schemas and data)
• Third party components
• Application servers such as IIS, BizTalk, MOSS etc.
• Additional utilities such as code generators, unit test frameworks and the like

It is not unknown for configuration of these elements to take days, during which the developer is unlikely to be doing anything particularly productive. This cost may also be incurred in the event that an existing development machine fails or becomes corrupted to a level requiring reinstallation. This can be seriously negative to a project schedule. Additionally, when external dependencies are varied (such as a new version of a component is adopted) there can be a cost required to ensure that the new version is made available to the entire development team in a consistent and reliable fashion.

There are a number of strategies that can reduce the effort required to build a development environment.

• Document the process of building the environment and keep the documentation current. This removes the reliance of human memory to ensure every configuration item is performed.
  
• Wherever possible make common software such as application servers and DBMSes part of the SOE so that developers do not need to spend time installing them.
  
• Rather than implicitly assuming that the correct version of a third party component is installed keep them in source control and reference them explicitly. You should organise your source control structure such that external dependencies are kept per version so that updating a component in one version of your software does not update it for all versions, risking breaking those versions and changing them unnecessarily.
• Keep minor tools in source control rather than requiring them to be installed. This obviously will not apply to such things as your IDE, but smaller utilities such as code generation tools or installer builders can be suitable candidates. This allows the build system to assume that these tools will be available across every environment.
  
• Automate as much as possible the configuration of the environment, including such elements as creating and populating databases and the configuration of application servers. This ensures that each environment will be similar in it's important aspects, which is important in ensuring that application behaviour is consistent. This automation should support multiple environments so that it may be applied in development, intergration, UAT, production or whatever other environments are used.