The Myth of Change Control

The Software Engineering model of Software development has a major flaw. There is an association with a linear, sequential process, we even have a neat name for this linear, sequential process, the "Waterfall" life cycle, where everything flows neatly from one stage or phase to another. Although this "waterfall" process of software development has supposedly been proven to be invalid, most software developers still talk as if it is alive and well.

For example we still talk about "doing requirements", "doing design" etc. This phrasing expresses the thought that requirements can, in some way, be completed. This sounds like a sequential, linear process to me. Even supposedly standard, mechanical, processes are not always as linear as we think. This was literally brought home to me recently while having some rooms painted. Although we had chosen the colors, it was not until the paint was on the walls did we really get to experience the effect the colors would have on the living space. Sitting down looking through the house changed the desirability of different colors, such that different walls were painted different colors as the overall experience was balanced.

It is as if our minds are conditioned to think in terms of sequences or cause and effect. Anything that does not fit within these expected sequence needs to be prevented or controlled so that it will not upset the smooth running of the development process. As a result, the software field has developed elaborate procedures for enforcing the sequence, establishing "change control procedures". What we should really do is establish "change recognition procedures". Change Control implies that software developers have a mechanism for controlling the changes, that they have some influence over their environment.

Change Recognition has a much different implication. It lets developers know that they have to build the possibility of change into their software, and at the same time lets them know that it is not necessarily a continuous process. There are several parts to this. The need to identify that a change has occurred, the ability to choose when to react to, and how to react to, the requested changes, the consequences of ignoring the changes and the consequences of implementing the changes.

Identifying that a change has occurred is not always an easy task. Most great software changes the way that people work, so it is only after the users have become comfortable with the new system that the real implications become apparent. Also changes can sneak up on you as was the case for Usenet News. When the number of people participating in online communities was small, Usenet was an effective mechanism for online discussions. As the number of participants rises, so does the message volume, such that at some point it becomes impossible for participants to keep up to date with the discussions.

Choosing when to recognize the change is a critical decision for software developers. Recognizing every minute change often means that it is impossible to make any progress towards delivering the system. Recognizing change infrequently carries with it the risk of getting too far out of touch with reality such that the system no longer meets the real needs of the users.

The choice of how to react to a requested change is also a critical choice for software developers. In the old days of "frozen" specifications, it was simple. Each requested change would be documented and declined. Now it is more a case of determining how the requested change should be implemented, whether the change fits within the current architecture, or whether the architecture needs to be adjusted to fit.

The consequences of ignoring a change are very tightly linked to the consequences of implementing a change. Whether a change should be ignored or implemented depends to a large degree on the vision for the system. Without a clear conceptual model for a system, there is no clear basis for deciding whether to recognize a change or not. Sometimes to implement a change it is better to create a completely new system that can handle the request in a more focused manner. An example of this is using a WEB Browser as a News reader, yes, it is possible, and no, it is not recommended.

Thus Change Recognition calls out a different paradigm, one where change is continual and systems have to evolve over time to keep aligned with these changes. Change Control on the other hand is much more oriented towards the developers than the end users.

(C) 1997,1999 Software Craftsmanship Inc., all rights reserved.