The Illusion of Control in Software Configuration Management

codeline and discovers that the code does not compile, much less pass tests. What has happened is that Otto and Sue made incompatible changes. Because the tests took so long to run, they made lots of changes, increasing the chances that the changes would conflict. Figure 1 illustrates this.

Figure 1: Phase Shifts and Testing

The team’s manager, Beth, sees a problem in need of a solution and declares that henceforth the team shall use an integration token. Only one person shall perform a check-in at a time. The check-in process is:

• Grab the integration token.
• Update your workspace from the codeline, resolving any conflicts.

• Run the test suite.

• When the test suite passes, check in the code.

• Pass the integration token on to the next person in the queue.

The problem of conflict is resolved, but now Beth notices that the rate at which features are being added to the code is slowing down. Only one person can do a check-in every 2 hours or so, which means that, at most, 4 people can check in changes at once now. In reality it may be less because there will always be people with commitments after work meaning that they should not even start the check-in process less than 2 hours before they need to leave.

While trying to fix the immediate problem, Beth created a longer term problem. A lack of quality leads one to want more control, which reduces quality in another dimension. Figure 2 illustrates this. For some applications with critical systems and small teams, this approach may work well, but in many cases the dominant business need is to change the codeline to add features.

Figure 2: Feedback between control and quality

How do we fix this? We can follow both lean and agile principles (which, at their heart, are similar) and try to address the core problems: Facilitating flow and eliminating waste. Some of the SCM Patterns address this.

Continuous Improvement in Context
Beth took a situation that was out of control and tried to control it, applying the theory that slower is safer. In some cases that’s true. Slower often gives you more chances to correct yourself and react, but slow might not be safer in all cases. When driving a vehicle, it often appears safer to drive slow. Yet sometimes driving conditions such as mud or sand create a “viscous cycle” where it becomes vitally important to maintain a minimum threshold speed, otherwise you get stuck in a rut and can’t get out of it.

Heavyweight configuration management environments that make developers wait non-negligible periods of time for things like check-out-authorization, presenting and approving all files to be modified prior to coding, protracted build-and-test cycles, waiting for a new baseline to be promoted for use, etc. are considered detrimental to the health of an agile development environment.

To solve the real problem consider what your goals are. If you want an Active Development Line, you want a codeline that is in good shape most of the time, but rapidly evolving. A codeline that never changes will always be safe, but you are not adding much business value.

The SCM Pattern Language shows you one way to resolve these issues. Figure 3 shows the relevant patterns. You create an Active Development Line by having developers work in a Private Workspac e. Before anyone checks code in to the codeline, developers must do a Private System Build and run a Smoke Test . The Smoke Test should quick to run, even if it is not comprehensive.

At this point you are probably asking yourself how