Vaccaperna logo


Contact us


Software Configuration Management (SCM)





What is SCM


Our favourite definition of Software Configuration Management is:

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.


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)

There are a number of other definitions maintained by Brad Appleton.

From Vaccaperna's recent work, for example in the mobile phone customer care and billing market, it is clear that many organisations still have problems really getting to grips with SCM - its importance is usually recognised but the practical implementation is frequently poor.



SCM Processes


It is interesting to see the divide in the tools market between the "process driven" tools and the others. This divide can be more artificial than real, in that an effective process can be designed around a variety of tools. The key is in the implementation, which is where Vaccaperna applies its knowledge and experience of the software development process across a number of industry sectors.

It is vital to implement a process that achieves control but does not leave developers feeling they have to go through layers of red tape to get the smallest thing done. With experience, planning, and the use of a powerful yet inexpensive tool such as Perforce, 20% of the cost can reap 80% of the gains in properly controlled software development.



SCM Links on the Web


The first ports of call are:

SCM FAQ from newsgroup

SCM Yellow Pages




Branching Patterns


There are a couple of excellent papers. The first is written by Perforce but is generic in nature and well worth reading: High Level Best Practices.

The second is the excellent set of branching patterns written by Brad Appleton and others: Streamed Lines - Branching Patterns for Parallel Software Development


Back to the top

Contact us

© Vaccaperna Systems Ltd