The Conifer Systems Blog

What is Configuration Management?

no comments

According to our contact info, our company is a “provider of software configuration management tools.”  So what is “configuration management,” anyway?

Let’s start by saying that I have never been a big fan of the term “configuration management.”  Everywhere that I read about “configuration management,” I feel like I should get out a Buzzword Bingo card with boxes like “agile” and “scrum.”  It seems to be a standard term in the industry, though, so I guess we have to go with it.  Rather than quoting you buzzword-laden slogans from other folks, let me instead offer my own definition: configuration management means “building better processes for building software.”

A good process is one that enhances the productivity of your team, so that you can deliver your users the functionality they need and want, deliver it sooner, and deliver it at a higher quality.  A bad process is one that impedes the productivity of your team, usually either through excessive bureaucracy or what I call thrashing.

We’re all familiar with excessive bureaucracy (“Before you are allowed to commit your changes, please submit a witnessed, notarized, signed copy of Form 7C and we will evaluate your change request at the next biweekly meeting”), but what’s thrashing?

Thrashing means everyone is working hard, but you still aren’t making much progress towards your destination.  Maybe you’re building functionality that your customers don’t need or want, or low priority features rather than essential ones.  Maybe you’re taking so many shortcuts writing the software that you’re writing low quality code full of bugs, costing you more time down the road.  Maybe your bug fixes are introducing new bugs, so the quality of your software isn’t improving even though everyone is scrambling to fix bugs as fast as they are reported.

Maybe management is telling engineers to work on project A in the morning and then changing their mind in the afternoon — now project B is more important — and again the next day — sorry, project A is more important after all.  Maybe people are frequently pulled off their tasks to help out with a tradeshow or other customer demo.  Maybe two engineers are both rewriting the same code in their local trees, not realizing that their changes are about to collide with one another.  Maybe your build or regression test is always broken, and by the time a fix is checked in, new build or regression test breaks have been checked in on top of the existing break.  Maybe your build process is not automated and poorly documented, so that when any two different people build their trees, they end up with different binaries, and people can’t reproduce each other’s bugs.

That’s thrashing.  Under these circumstances, you can work as hard as you want, and you won’t accomplish much.  It’s always tempting to say that everyone just needs to work even harder (more overtime!).  Management sees that the schedule is slipping and sends out an email of “encouragement” saying “we promised to ship on date X — look, we can’t break our promises to customers, so get cracking, people!”  This rarely helps.  (A particularly dishonest but common management tactic is to tell one “aggressive” release date to the engineers and another “conservative” release date to the customers.)

We can’t really help you with excessive bureaucracy.  If your developers spend 5 hours a day sitting in meetings and reading and sending email, sorry, there’s not much we can do about that.  But when it comes to thrashing, better tools can definitely help.

Think about how you or your developers spend a typical day.  I’ll give an example from personal experience.  On several projects I formerly worked on, it would be common for me to spend the first 1-2 hours of each day:

  • Downloading the latest source code from the revision control system
  • Building the software, and addressing any build breaks I hit along the way
  • Running some simple tests on the software, to make sure some basic things work, and fixing or reporting any bugs I hit along the way

Of course, I might get stuck.  If I hit a bug that I couldn’t solve myself, I might have to wait for someone else to fix it.  I’m a big believer in jumping on problems aggressively to unblock the rest of the team as quickly as possible  (if you can fix a build break, go ahead and commit immediately — don’t wait for someone else to fix it), but you have to be careful: it’s irresponsible to make changes to code you don’t understand.  In that case, if the other person doesn’t fix the problem promptly, you can spend days waiting.  (Hopefully you have other projects you can work on so you don’t just have to sit there browsing the web all day.)  Again, this has happened to me on real projects many times.

Wouldn’t it have been better if I could have shortcut those first 1-2 hours of each day and been able to set up a pre-built, pre-tested tree in seconds with Cascade?

Wouldn’t it have been better if those changes that broke builds or regression tests had been rejected — not allowed to be committed into the repository in the first place?

That’s what good configuration management is all about to me.  It’s about building processes that aren’t bureaucratic — they allow people to spend their time doing work rather than jumping through unnecessary hoops and sitting in boring meetings — and increase everyone’s productivity by reducing thrashing.

You’ll never hear me talk about “agile CM” or whatever the latest buzzwords are.  Configuration management is too important to be reduced to marketing buzzwords and slogans.  There’s real substance behind it, and the processes good configuration management engineers build can be the difference between shipping low quality software late and shipping high quality software on time.

Written by Matt

September 12th, 2008 at 5:17 pm

Leave a Reply