The Unchangeable Rules of Software Change

makes it slip out of control

The more you try to deny and defy rule #2 by attempting to precisely predict, or rigidly control change, the more erratic and onerous the result will be.

Rule #4: Embrace change to control change

The more flexible and adaptive you are at accommodating change, the more control you will have over your outcomes.

These rules are very hard to accept! Often, they are accepted only one at a time, after much frustration and over a period of hard learning and reflection. The stages one passes through while learning these rules bears more than a passing resemblance to "the five stages of grief."

Traditional Change-Control
When faced with a requested or impending change that impacts the scope of the project, generally accepted best-practice is to utilize a Change-Control Board (CCB) consisting of your project's key stakeholders:

• Assess the impacts of the change make those known to your stakeholders
• Present the viable options the risks associated with each one (possibly accompanied by a recommendation)

• Let them decide which option to "exercise" based on informed consent, making sure they are fully cognizant of the benefits, consequences, and risks of the chosen option.

Still, the idea of giving up control to another group every time a change arises isn't always palatable. And of course there is also the fear that every a scope change that becomes visible will make them look bad, as if they don't really know what they are doing.

Recently I was talking to a group that was struggling with rule #2. They thought if they could only do even more detailed specification up-front (they already do a reasonable amount of up-front detail), that it would somehow eliminate problems with estimation accuracy, which in turn would alleviate problems with "conformance to plan" and prevent the details from being discovered later (because they would instead get them all "right" up-front).

Despite having plenty of historical evidence/data in this particular product to support the "inescapable truth" laid out by these rules, there still seemed to be that desire to cling to the illusion of control that we can somehow prevent such changes if only we spend more time & effort getting a more complete, perfect & detailed specification up-front near the very beginning.

Software Evolution & Feedback
As it so happens, I don't always come across as authoritatively sage as I might hope. So I looked for some materials from other folks more sagacious and experienced than myself. The first that came to mind was Lehman and Belady's Laws of Software Evolution (ca.1971) and the subsequent work on the FEAST Projects . Those are primarily about software maintenance however, and refer to the inevitability of needing to maintain and evolve an already released piece of software. They don't speak quite as strongly to the inevitability of changes via feedback, discovery and learning during the course of any non-trivial software development effort.

So I searched a bit more and came across a handful of particularly interesting (to me) references that are quite recent:

• Phil Armour's Jan 2006 CACM article Counting Boulders and Measuring Mountains: Accuracy and the Measurement of Peaks and Projects (Phil's book The Laws of Software Process is one of my favorites)
• Chapter 2 of Karl Wieger's newest book More About Software Requirements (Microsoft Press, 2006; ISBN 0-7356-2267-1) entitled "Cosmic Truths About Software Requirements"

• A recent gem of a posting from Per Kroll , Director at Rational Software and co-author with Phillipe Kruchten of " The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP" , posted on the IBM/Rational "RUP" discussion forum