Section 10.1. Maintaining an Environment

10.1. Maintaining an Environment

The useful life of the tools that make up a development environment is generally much longer than the life of the products that were created using the environment. No one wants to have to use a different bug tracking tool or a new build tool for every different release of the product. However, environments and their tools do age with time, and as tools are replaced with other tools, the environment gradually changes. The environment that you wrote code in 10 years ago is not the same one that you use noweven Emacs and vi have changed in that time. It's also probably faster now than it was back then.

What's important is that older tools and their environment still have to be maintained until all the products that were developed with them are no longer supported. It's very frustrating to spend time learning about an older version of a product and making changes to the source code, only to find that you're unable to build and test that version, or that something else has changed in the environment and now you have to spend time working out what it was.

Part of maintaining an environment is checking that the versions of the tools that you use are still supported. Using the latest version of any tool is somewhat risky, but is acceptable if the tool does just what you need it to. However, beware of the total amount of time that can be spent upgrading to every new version of a tool.

Why do tools rot?

Code rot is a casual way of describing what happens when a piece of source code is not regularly maintained. As the source code around it gradually changes, that piece of code eventually stops working or, even more annoyingly, causes bugs to spontaneously appear in the product. A similar kind of decay called tool rot occurs with development environments when tools are not used for a while and then don't work when you want to use them.

There are at least five common reasons why tools stop working properly when development environments change:

Operating system changes

A tool may work with only certain versions of an operating system. If a developer's machine is upgraded to a newer version of the operating system, then this may prevent older versions of the product that still use the tool from being built.

Command-line argument and API changes

If the arguments passed to a tool change in number or order, or the API to the tool changes in some other way, then the tool may not work properly in older environments.

Data format changes

If the format of the data given to a tool for input (or expected from a tool as output) is changed, then the tool may stop working properly, or may create hard-to-detect errors in the data when used in older environments.

Licenses

You may simply not realize that a license key for a tool has expired, especially if the tool is part of an infrequently used older version of your environment.

Mergers and acquisitions

When companies or projects join forces, their development environments usually undergo large changes. The best tools should win, but sometimes the survivors are those that are used by the largest number of people, or that it would take the most effort to migrate data from.

The remedy for tool rot is to regularly use the older environment. Changing either the environment and tools or the product's use of the tools, but not both at the same time, will also help you avoid tool rot.

The more common case is environments that are set up but never maintained until some key tool stops working. Then the pressure to solve the problem, along with the ensuing discussions about fixing or replacing the tool, can greatly distract people from developing the actual product. Instead, it's far better to regularly monitor all the tools that are used, and to maintain a sense of the effort and cost to make particular changes to your environment. You can then decide whether to postpone upgrades and deal with the inevitable crises, or to spend the time to gradually upgrade tools before they break. Also, mistakes happen and priorities change in a project. If you have a good understanding of the costs of changing the environment's tools, then you're better placed to deal with these unplanned changes.

Some estimated life spans of different kinds of tools in a typical small to medium-sized project are shown in Table 10-1. These are the times before the tool is replaced with an entirely new tool, not just the intervals between upgrades. The values are subjective, based on my own experience and observations about when the larger open source projects have changed the tools in their development environments over the past 15 years.

Table 10-1. Typical tool life spans

Tool	Life span (years)
SCM tool	5-10
Build tool	8-15
Test environment	3-6
Bug tracking system	3-5
Documentation environment	5-10

Ideally, a development environment's own SCM tool should be able to track all the changes in the development environment, including changes to the SCM tool itself. In practice, many of the tools used in an environment are inconveniently large for tracking with existing SCM tools. Operating systems can be checked in to SCM tools but they rarely are, for just this reason. In this case, making copies of the important disks, CDs, and DVDs is appropriate. Another approach that's quicker when you want to reproduce an environment later on is to use Norton Ghost, g4u, or VMware to create copies of key machines, and then to store those copies elsewhere.

Even if the original files for the tools themselves are too large for your SCM tool, you can use files that describe the environment, and these files can be controlled using your SCM tool. One approach is to use a collection of files named the environment documents. Some of these files are updated by hand (for example, when processes and policies change). Other files can be automatically updatedfor instance, if the build tool generates a list of tools used and their versions. This is also a good place to record the location of copies of large tools.

Another aspect of a development environment that needs to be regularly maintained is the test environment, since making changes in an older environment is doubly hard if you don't have the same test environment that was originally used. Just as with the current environment, it's important to be able to use both development and production machines in an older environment.

10.1.1. Migrating Your Data

The purpose of many tools such as SCM tools and bug tracking systems is to make stored information easily accessible. Part of maintaining an environment is migrating data from one tool to another as you change which tools are in active use.

Good practice with data is to use well-defined and open (i.e., license-free) file formats. Structured ASCII text, XML, and Ogg Vorbis for audio are all examples of open formats.

Before adding data in whatever format a specific tool uses, you should ask yourself how you could extract the data in the future. Many tools such as Microsoft Word use proprietary formats that only tools from the creator can fully understand. This is, of course, part of the sales strategy for such tools: if you can't extract your files and data from the tool, you are locked in to the tool and can be forced to pay for upgrades, generating more income for the product. The simple test of how easy it will be to migrate away from a tool is to search the tool's documentation for "export" and "Save As." Count the number of different formats that are supported and compare this to the number of different data formats that the tool can import. The numbers should be about equal.

Data migration is one part of defining an exit strategy for the tools in your environment. You can't define the tools that you will use five years from now, but you can make it easier to change to those tools when you have to.