Development Environment ChecklistAny software project larger than a few person-weeks will benefit from a carefully crafted development environment. This includes tools such as compilers, editors, debuggers, the build system and the configuration management system.
The software development environment has a major effect on productivity. A good environment will allow developers to get on with their jobs and build software quickly. A poor environment will see the developers battling every step of the way.
Your organisation may already have a full development environment that your project is expected to use. In this case use this checklist to ensure that it is appropriate for this project.
- Tools Documented
The names, version numbers and configuration of all tools used are formally documented so that new development machines can be set up consistently.
It is important to document the toolset so that new machines can be set up in the event of hardware failures, change of equipment or new developers starting on the team.
A useful approach is to get one of the more junior team members to be responsible for setting up PCs and maintaining this documentation. Occaisionally assign others to configure tools as a check of the quality of the documentation.
- Tools Useful to this Project
The tools used are appropriate for this project.
Tool administration and use can take a large chunk of time. Be careful to check each tool to ensure that it is useful for this project. This is especially important where the project has inherited a development environment.
- Unwanted Side-Effects Avoided
The tools used do not impose artificial and unwanted restrictions on the end product.
Many tools leave some kind of 'mark' on the finished product. For example, some IDEs (Integrated Development Environments) require that you ship vendor-specific libraries with your finished code.
Double-check the project's technical requirements to ensure that any such limitation is acceptable.
The build system takes source code and 'builds' it to produce the software product that is to be delivered.
For smaller projects, the entire build system might be within an Integrated Development Environment. For larger projects, however, it is quite common for a build system to be very complex and to include a mixture of manual and automated steps.
- Build System Documented
The design and operation of the build system is formally documented so that 'anyone' can build the system.
All to often, a project relies upon one or two people to understand the development environment, to the point where these people are the only ones that can actually build the complete system. This works OK until, at some critical point, these people are not available.
To avoid this risk, document the build system and share the task of operating the build system between developers.
- Consistent Delivery
The build system produces consistent results: two builds from the same source code will produce the same result.
Because 'the build' is almost always on the critical path, a build system that produces inconsistent results is a distinct threat to on-time delivery.
Here are some suggestions to help achieve consistent builds:
- Have step-by-step build documentation that is checked off by the builder.
- Automate as much of the build as possible.
- Work with the configuration management system to ensure that the configuration of the source code used to do the build is precisely known.
- Review every bad build. Find out what went wrong, and determine how to prevent it from affecting the project again.
- Automatic Overnight Builds
Builds are performed regularly to check for compilation and other errors.
It is a good idea to ensure that the system is built every night to weed out compilation errors on a daily basis.
The general principle is, of course, that there should never be any compilation errors, because developers only check-in code that compiles with all the other code that has already been checked in.
In practice, there will at least be occasional errors that need to be found, reported and corrected.
If possible, have the build system run an automated test harness against the newly built code to detect further errors.
The Configuration Management system allows developers to know exactly which versions of which development artifacts and inputs they are using. It allows bugs to be traced quickly, especially on large or long-running projects.
Typically the configuration management system is integrated with the build system in some way.
- Appropriate Configuration Management In Place
The configuration management system used by the project is appropriate to the project.
The definition of 'appropriate' varies greatly depending on the organisation's goals. Short projects with a small number of developers will require only very simple systems. On very small projects, a completely manual system may suffice.
For larger projects it may be cost effective to use sophisticated configuration management tools costing hundreds of thousands of dollars.
Factors to consider in developing a configuration management system and deciding on a product are:
- Whether there will be concurrent streams of development. This is where two or more teams of developers are making additions and modifications to the same source code base.
- The frequency of releases.
- The number of developers and length of the project.
- The complexity of dependencies between developers.
- Configuration Management System Documented
The configuration managment system is documented so that 'anyone' can use and administer it.
As with the build system, it is important that knowledge of the configuration management system be shared amongst many people.
- Configuration Manager(s) Identified
A person or group of people have been identified as the project's configuration managers.
Configuration management is typically more complex than build management and hence requires a greater degree of specialisation. In projects with moderate to complex configuration management needs, it will be necessary to appoint a configuration manager who is responsible for administering the configuration management system.
As noted above, more than one person should be capable of filling this role, which may mean that the role has to be shared or rotated between multiple people.
As with any software system, the development environment will occasionally be affected by software or hardware failure. Since the software development environment is critical to a software project, such eventualities should be planned for.
Most organisations put a fair amount of effort into Business Continuity Plans. If possible, secure the assistance of one of your company's business continutity planners to help with the 'Development Environment Continuity Plan'.
- Plan Documented
The recovery plan is formally documented and available for immediate access in an emergency.
As a precaution, make sure that at least one printed copy of the report exists.
- Software Failure Covered
The plan addresses software failures such as corruption of the configuration management repository.
The plan in this case might be to take nightly backups, so that a maximum of one day's work is lost. Note that the restoration procedure needs to be tried and tested: backups that cannot be restored when they are most needed are terribly disheartening.
- Hardware Failure Covered
The plan addresses hardware failures, including failure of key development servers and individual developer machines.
The plan should state the effect of the loss of any of the hardware used by the project, and how the effect will be minimised. For instance, if your development server were stolen (and I have worked on one project where it was!), how would you get the development team working again?
Also, the plan should state what will be done if a developer's machine develops a defect. Can a new machine be located quickly and have a complete development environment loaded onto it? Would any of the developer's work be lost with the loss of a PC?