What is Software Configuration Management (SCM)?

As far back as 1986 Configuration Management was being considered as a means of eliminating the confusion that populates every extensive development effort.

On any team project, a certain degree of confusion is inevitable. The goal is to minimize this confusion so that more work can get done. The art of coordinating software development to minimize this particular type of confusion is called configuration management. Configuration management is the art of identifying, organizing, and controlling modifications to the software being built by a programming team. The goal is to maximize productivity by minimizing mistakes.

Wayne Babich
Software Configuration Management: Coordination for Team Productivity
Addison-Wesley, 1986.

At that time Software Configuration Management often consisted of nothing more than checking files in and out - occasionally assigning a version label.  Many development team members were often tasked to perform their own Configuration Management - or perhaps a member of the SQC Team was drafted part-time to fill the Configuration Management requirements.  There was an understanding that Configuration Management was needed, but it wasn't exactly understood what Configuration Management did.

Today good Configuration Management has proven itself to be an invaluable set of processes that provide solutions to the frustrating confusion and problems.  When development teams and Configuration Management work in harmony,  much burden is alleviated from those developers allowing them to concentrate more on the tasks at hand.

The most frustrating software problems are often caused by poor configuration management. The problems are frustrating because they take time to fix, they often happen at the worst time, and they are totally unnecessary. For example, a difficult bug that was fixed at great expense suddenly reappears; a developed and tested feature is mysteriously missing; or a fully tested program suddenly doesn't work. Configuration management helps to reduce these problems by coordinating the work products of the many different people who work on a common project. Without such control, their work will often conflict, resulting in such problems as:

Simultaneous Update

When two or more programmers work separately on the same program, the last one to make the changes can easily destroy the other's work.

Shared Code

Often, when a bug is fixed in code shared by several programmers, some of them are not notified.

Common Code

In large systems, when common program functions are modified, all the users need to know. Without effective code management, there is no way to be sure of finding and alerting every user.

Versions

Most large programs are developed in evolutionary releases. With one release in customer use, another in test, and a third in development, bug fixes must be propagated between them. If found by a customer, for example, a bug should be fixed in all later versions. Similarly, if a bug is found in a development release, it should be fixed in all those prior versions that contained it. In larger systems with several simultaneous active releases and many programmers working on bug fixes and enhancements, conflicts and confusion are likely.

These problems stem from confusion and lack of control, and they can waste an enormous amount of time. The key is to have a control system that answers the following questions:

• What is my current software configuration?
• What is its status?
• How do I control changes to my configuration?
• How do I inform everyone else of my changes?
• What changes have been made to my software?
• Do anyone else's changes affect my software?

The key role of Software Configuration Management (SCM) is to control change activity so these questions can be answered. If, however, SCM is viewed merely as a management tool or contractual obligation, it can easily become a bureaucratic roadblock that impedes the work. While such systems may be contractually required, the real need is to assist the programmers in controlling and tracking their work, while ensuring that nothing is lost or destroyed.

Watts Humphrey
Managing the Software Process
Addison-Wesley, 1989