28.2. Configuration Management

A software project is dynamic. The code changes, the design changes, and the requirements change. What's more, changes in the requirements lead to more changes in the design, and changes in the design lead to even more changes in the code and test cases.

What Is Configuration Management?

Configuration management is the practice of identifying project artifacts and handling changes systematically so that a system can maintain its integrity over time. Another name for it is "change control." It includes techniques for evaluating proposed changes, tracking changes, and keeping copies of the system as it existed at various points in time.

If you don't control changes to requirements, you can end up writing code for parts of the system that are eventually eliminated. You can write code that's incompatible with new parts of the system. You might not detect many of the incompatibilities until integration time, which will become finger-pointing time because nobody will really know what's going on.

If changes to code aren't controlled, you might change a routine that someone else is changing at the same time; successfully combining your changes with theirs will be problematic. Uncontrolled code changes can make code seem more tested than it is. The version that's been tested will probably be the old, unchanged version; the modified version might not have been tested. Without good change control, you can make changes to a routine, find new errors, and not be able to back up to the old, working routine.

The problems go on indefinitely. If changes aren't handled systematically, you're taking random steps in the fog rather than moving directly toward a clear destination. Without good change control, rather than developing code you're wasting your time thrashing. Configuration management helps you use your time effectively.

In spite of the obvious need for configuration management, many programmers have been avoiding it for decades. A survey more than 20 years ago found that over a third of programmers weren't even familiar with the idea (Beck and Perkins 1983), and there's little indication that that has changed. A more recent study by the Software Engineering Institute found that, of organizations using informal software-development practices, less than 20 percent had adequate configuration management (SEI 2003).

Configuration management wasn't invented by programmers, but because programming projects are so volatile, it's especially useful to programmers. Applied to software projects, configuration management is usually called "software configuration management" (SCM). SCM focuses on a program's requirements, source code, documentation, and test data.

The systemic problem with SCM is overcontrol. The surest way to stop car accidents is to prevent everyone from driving, and one sure way to prevent software-development problems is to stop all software development. Although that's one way to control changes, it's a terrible way to develop software. You have to plan SCM carefully so that it's an asset rather than an albatross around your neck.

On a small, one-person project, you can probably do well with no SCM beyond planning for informal periodic backups. Nonetheless, configuration management is still useful (and, in fact, I used configuration management in creating this manuscript). On a large, 50-person project, you'll probably need a full-blown SCM scheme, including fairly formal procedures for backups, change control for requirements and design, and control over documents, source code, content, test cases, and other project artifacts. If your project is neither very large nor very small, you'll have to settle on a degree of formality somewhere between the two extremes. The following subsections describe some of the options in implementing SCM.

Cross-Reference

For details on the effects of project size on construction, see Chapter 27, "How Program Size Affects Construction."

Requirements and Design Changes

During development, you're bound to be bristling with ideas about how to improve the system. If you implement each change as it occurs to you, you'll soon find yourself walking on a software treadmill for all that the system will be changing, it won't be moving closer to completion. Here are some guidelines for controlling design changes:

Cross-Reference

Some development approaches support changes better than others. For details, see Section 3.2, "Determine the Kind of Software You're Working On."

Follow a systematic change-control procedure As Section 3.4 noted, a systematic change-control procedure is a godsend when you have a lot of change requests. By establishing a systematic procedure, you make it clear that changes will be considered in the context of what's best for the project overall.

Handle change requests in groups It's tempting to implement easy changes as ideas arise. The problem with handling changes in this way is that good changes can get lost. If you think of a simple change 25 percent of the way through the project and you're on schedule, you'll make the change. If you think of another simple change 50 percent of the way through the project and you're already behind, you won't. When you start to run out of time at the end of the project, it won't matter that the second change is 10 times as good as the first you won't be in a position to make any nonessential changes. Some of the best changes can slip through the cracks merely because you thought of them later rather than sooner.

A solution to this problem is to write down all ideas and suggestions, no matter how easy they would be to implement, and save them until you have time to work on them. Then, viewing them as a group, choose the ones that will be the most beneficial.

Estimate the cost of each change Whenever your customer, your boss, or you are tempted to change the system, estimate the time it would take to make the change, including review of the code for the change and retesting the whole system. Include in your estimate time for dealing with the change's ripple effect through requirements to design to code to test to changes in the user documentation. Let all the interested parties know that software is intricately interwoven and that time estimation is necessary even if the change appears small at first glance.

Regardless of how optimistic you feel when the change is first suggested, refrain from giving an off-the-cuff estimate. Such estimates are often mistaken by a factor of 2 or more.

Be wary of high change volumes While some degree of change is inevitable, a high volume of change requests is a key warning sign that requirements, architecture, or top-level designs weren't done well enough to support effective construction. Backing up to work on requirements or architecture might seem expensive, but it won't be nearly as expensive as constructing the software more than once or throwing away code for features that you really didn't need.

Cross-Reference

For another angle on handling changes, see "Handling Requirements Changes During Construction" in Section 3.4. For advice on handling code changes safely when they do occur, see Chapter 24, "Refactoring."

Establish a change-control board or its equivalent in a way that makes sense for your project The job of a change-control board is to separate the wheat from the chaff in change requests. Anyone who wants to propose a change submits the change request to the change-control board. The term "change request" refers to any request that would change the software: an idea for a new feature, a change to an existing feature, an "error report" that might or might not be reporting a real error, and so on. The board meets periodically to review proposed changes. It approves, disapproves, or defers each change. Change-control boards are considered a best practice for prioritizing and controlling requirements changes; however, they are still fairly uncommon in commercial settings (Jones 1998, Jones 2000).

Watch for bureaucracy, but don't let the fear of bureaucracy preclude effective change control Lack of disciplined change control is one of the biggest management problems facing the software industry today. A significant percentage of the projects that are perceived to be late would actually be on time if they accounted for the impact of untracked but agreed-upon changes. Poor change control allows changes to accumulate off the books, which undermines status visibility, long-range predictability, project planning, risk management specifically, and project management generally.

Change control tends to drift toward bureaucracy, so it's important to look for ways to streamline the change-control process. If you'd rather not use traditional change requests, set up a simple "ChangeBoard" e-mail alias and have people e-mail change requests to the address. Or have people present change proposals interactively at a change board meeting. An especially powerful approach is to log change requests as defects in your defect-tracking software. Purists will classify such changes as "requirements defects," or you could classify them as changes rather than defects.

You can implement the Change-Control Board itself formally, or you can define a Product Planning Group or War Council that carries the traditional responsibilities of a change-control board. Or you can identify a single person to be the Change Czar. But whatever you call it, do it!

I occasionally see projects suffering from ham-handed implementations of change control. But 10 times as often I see projects suffering from no meaningful change control at all. The substance of change control is what's important, so don't let fear of bureaucracy stop you from realizing its many benefits.

Software Code Changes

Another configuration-management issue is controlling source code. If you change the code and a new error surfaces that seems unrelated to the change you made, you'll probably want to compare the new version of the code to the old in your search for the source of the error. If that doesn't tell you anything, you might want to look at a version that's even older. This kind of excursion through history is easy if you have version-control tools that keep track of multiple versions of source code.

Version-control software Good version-control software works so easily that you barely notice you're using it. It's especially helpful on team projects. One style of version control locks source files so that only one person can modify a file at a time. Typically, when you need to work on source code in a particular file, you check the file out of version control. If someone else has already checked it out, you're notified that you can't check it out. When you can check the file out, you work on it just as you would without version control until you're ready to check it in. Another style allows multiple people to work on files simultaneously and handles the issue of merging changes when the code is checked in. In either case, when you check the file in, version control asks why you changed it, and you type in a reason.

For this modest investment of effort, you get several big benefits:

• You don't step on anyone's toes by working on a file while someone else is working on it (or at least you'll know about it if you do).

• You can easily update your copies of all the project's files to the current versions, usually by issuing a single command.

• You can backtrack to any version of any file that was ever checked into version control.

• You can get a list of the changes made to any version of any file.

• You don't have to worry about personal backups because the version-control copy is a safety net.

Version control is indispensable on team projects. It becomes even more powerful when version control, defect tracking, and change management are integrated. The applications division of Microsoft found its proprietary version-control tool to be a "major competitive advantage" (Moore 1992).

Tool Versions

For some kinds of projects, it may be necessary to be able to reconstruct the exact environment used to create each specific version of the software, including compilers, linkers, code libraries, and so on. In that case, you should put all of those tools into version control, too.

Machine Configurations

Many companies (including my company) have experienced good results from creating standardized development machine configurations. A disk image is created of a standard developer workstation, including all the common developer tools, office applications, and so on. That image is loaded onto each developer's machine. Having standardized configurations helps to avoid a raft of problems associated with slightly different configuration settings, different versions of tools used, and so on. A standardized disk image also greatly streamlines setting up new machines compared to having to install each piece of software individually.

Backup Plan

A backup plan isn't a dramatic new concept; it's the idea of backing up your work periodically. If you were writing a book by hand, you wouldn't leave the pages in a pile on your porch. If you did, they might get rained on or blown away, or your neighbor's dog might borrow them for a little bedtime reading. You'd put them somewhere safe. Software is less tangible, so it's easier to forget that you have something of enormous value on one machine.

Many things can happen to computerized data: a disk can fail; you or someone else can delete key files accidentally; an angry employee can sabotage your machine; or you could lose a machine to theft, flood, or fire. Take steps to safeguard your work. Your backup plan should include making backups on a periodic basis and periodic transfer of backups to off-site storage, and it should encompass all the important materials on your project documents, graphics, and notes in addition to source code.

One often-overlooked aspect of devising a backup plan is a test of your backup procedure. Try doing a restore at some point to make sure that the backup contains everything you need and that the recovery works.

When you finish a project, make a project archive. Save a copy of everything: source code, compilers, tools, requirements, design, documentation everything you need to re-create the product. Keep it all in a safe place.

cc2e.com/2843

Checklist: Configuration Management

General

• Is your software configuration management plan designed to help programmers and minimize overhead?

• Does your SCM approach avoid overcontrolling the project?

• Do you group change requests, either through informal means (such as a list of pending changes) or through a more systematic approach (such as a change-control board)?

• Do you systematically estimate the cost, schedule, and quality impact of each proposed change?

• Do you view major changes as a warning that requirements development isn't yet complete?

Tools

• Do you use version-control software to facilitate configuration management?

• Do you use version-control software to reduce coordination problems of working in teams?

Backup

• Do you back up all project materials periodically?

• Are project backups transferred to off-site storage periodically?

• Are all materials backed up, including source code, documents, graphics, and important notes?

• Have you tested the backup-recovery procedure?

Additional Resources on Configuration Management

cc2e.com/2850

Because this book is about construction, this section has focused on change control from a construction point of view. But changes affect projects at all levels, and a comprehensive change-control strategy needs to do the same.

Hass, Anne Mette Jonassen. Configuration Management Principles and Practices. Boston, MA: Addison-Wesley, 2003. This book provides the big-picture view of software configuration management and practical details on how to incorporate it into your softwaredevelopment process. It focuses on managing and controlling configuration items.

Berczuk, Stephen P. and Brad Appleton. Software Configuration Management Patterns: Effective Teamwork, Practical Integration. Boston, MA: Addison-Wesley, 2003. Like Hass's book, this book provides a SCM overview and is practical. It complements Hass's book by providing practical guidelines that allow teams of developers to isolate and coordinate their work.

cc2e.com/2857

SPMN. Little Book of Configuration Management. Arlington, VA: Software Program Managers Network, 1998. This pamphlet is an introduction to configuration management activities and defines critical success factors. It's available as a free download from the SPMN website at http://www.spmn.com/products_guidebooks.html.

Bays, Michael. Software Release Methodology. Englewood Cliffs, NJ: Prentice Hall, 1999. This book discusses software configuration management with an emphasis on releasing software into production.

Bersoff, Edward H., and Alan M. Davis. "Impacts of Life Cycle Models on Software Configuration Management." Communications of the ACM 34, no. 8 (August 1991): 104 118. This article describes how SCM is affected by newer approaches to software development, especially prototyping approaches. The article is especially applicable in environments that are using agile development practices.