One of the hardest questions that anyone in the configuration management (CM) field has to answer is “what do you do?” Because it is such a specialized field, and because the responsibilities given to CM specialists varies so widely from company to company, the explanations necessary to give an answer can be longer than the nightly news.
“We deal in software, friend.”
If the question is asked as a form of social lubricant—to pass the time waiting in line, say—a simple answer is usually best. “I do software configuration management. It’s a part of software development.” That way, if other parties know something about SCM, or if they know they need help with SCM, they also know where to go for help. But if, like 99.99% of people, they can’t even spell SCM, then they know it’s something to do with software development and they can start complaining about Microsoft, or talking about downloading illegal music, or whatever. Finally, if the question is asked by an attractive member of the opposite sex holding an alcoholic beverage, the answer is, “I’m a Lamborghini dealer.”
“It’s a form of project management.”
If the other party is a little more aware of the software business, or of engineering projects in general, the answer changes a little bit. Usually, a good starting point is “CM is a specialized part of project management.” This again gives them the chance to nod and say “Oh, I see…” as their eyes glaze over.
But what is Software Configuration Management, really?
Occasionally, someone insists on getting the painful details. Usually, this only happens with close relatives, or neighbors hoping you can help some relative find a job. But the question is worth answering, if only to bore them so severely that they’ll never ask again.
Knowing the Four W’s
One short-hand definition for CM is this: Configuration Management is about placing the blame. It totally fails to convey the value that CM offers, but it sums up the attitudes of most developers and can serve as a witty way to start talking about CM. In particular, it’s a good way to start talking about the four W’s: who made a change, why the change was made, what changed, and when.
Explaining to people about Sarbanes-Oxley, and why corporate governance is important, is a great analogy for software configuration management. Almost everyone remembers the “magic show” that happened with Worldcom and Enron—companies ‘magically’ converted from vital, working organizations one day into giant steaming piles of chopped liver the next day. And even if they don’t understand how it happened, the idea that SOX was created to prevent a recurrence of those disasters is pretty easy to get.
“Software development is like air travel”
Done right, configuration management is about more than being able to understand a disaster after it happened. Perhaps a better analogy is the safety measures put in place by the FAA. In addition to having a “black box” installed in every commercial airplane, they regulate the “air lanes” to keep traffic flowing smoothly, and require other safety measures, like special weather radar systems, to actively prevent problems. The “Four Ws” mentioned above correspond with the black box in each aircraft: if something bad happens, the sequence and causes can be understood. But other aspects of configuration and change control can help an organization anticipate and avoid (or minimize) problems.
Part of this is from good “traffic control.” Talking about the schedule and sequencing of builds, releases, deliveries to testing, deployments, and so on helps to prevent problems and conflicts when the changes are “in transit.” Beyond that, even the most basic metrics, like how long a build takes, or the average time to deliver a change, help project management understand and predict future schedules. And finally, monitoring the “weather”—the number and nature of open changes, particularly complex development or testing activities, the progress and status of builds and testcase execution—lets the “Change Traffic Controllers” detect unfavorable conditions and route traffic around them.
“Software CM is like tax accounting”
Back in the realm of how to explain CM without putting the audience to sleep, another good analogy is with tax accounting. It is a specialized segment of an already specialized field, and for the most part practitioners get to go home at a decent hour every day. Even the busy periods are pretty predictable, since you know when they’re coming. Configuration management, done right, is pretty much the same. You are a narrow specialist in an already specialized field, you get to go home at a decent hour every day, and your busy times are predictable.
A software CM consultant is a “fun vampire”
Not everyone doing software CM, or the tasks normally done by CM specialists, is going home at a decent hour. And managers on poorly run projects often find themselves surprised by unexpected blowups and sudden crises. (This is almost a tautology: if you’re a project manager, your job is to prevent surprises and avoid crises. If you get surprised, and it’s not a birthday, a lottery ticket, or Ed McMahon, then your project isn’t very well managed. Sorry.)
But we love that! Longacre gets paid for helping people do software CM. If nobody was having problems, we wouldn’t get paid. (That would be bad.) So we love it when projects are blowing up, getting their wires crossed, having changes, deployments, or entire releases crash into each other. That’s when we get to start working.
What’s more, that stuff is fun! Okay, maybe it’s not fun if you’re the manager in charge. But when you specialize in automating the development process, a large fraction of these problems are scripting problems. And they’re almost always “new-ish.” Sometimes the concepts are the same (“We want an automated build.”) but the particular details are usually different. And getting to write a bunch of code that will immediately help rescue a foundering project really is fun.
So another way to look at what we do—and by “we,” I mean software configuration management consultants, like Longacre, and not just SCM specialists—is that we are “fun vampires.” We travel around, looking for projects in need of scripting, automation, training, and system design to help them get back on track, and we feed off the fun parts. When we’re done, the fun has been drained out: manual tasks have been automated, standard procedures are in place, project team members have been trained, and in general the mid-air collisions, runway near misses, wind-shear crashes, and maintenance failures of out-of-control development groups have been replaced by a bunch of boring rules, prescribed paths from place to place, and a team of controllers continually monitoring the action. When a software development project is under control, it’s much less exciting. The thrill, as they say, has gone. And that’s how we know our work is done.