Why Software Configuration Management Metrics Are Important
A recent discussion on software configuration (SCM) metrics in the configuration management (CM) professionals group of LinkedIn started off well, but seemed to have taken a wrong turn—at least from what I can tell from reading some of the comments.
One contributor argued “that SCM metrics are futile.” Why? Because he says that SCM metrics measure SCM instead of business value. I believe, however, that SCM metrics are important. Software metrics help us build better software, and SCM metrics help us to better manage the built software.
I first got seriously interested in SCM metrics in the early 1980s when introducing a new software methodology at the Mitel Corporation. My team had an advanced (second generation) SCM tool that was home grown and went by the name of SMS. It covered not just version control, build management, and change control but also things like document management and project management—a forerunner of today’s ALM.
Software engineering pioneer Barry Boehm was a key inspiration for these metrics, especially from his book(s) on the Cocomo Model for project management estimation, which really helped us move from a late, partial contents delivery system to a predictable, on-time and on-budget capability.
Keeping all of this mind, I’ve come to believe that SCM metrics are not futile and are not even just neutral. In fact, they’re essential.
Take a look at the number of files you have in a particular update (i.e., change package). Also, look at the average time between your first file check-out and last file check-in for an update. If both of these are high, you’re going to have a lot of file contention and probably a branching strategy that is complex in order to resolve the contention. This results in lots of merges and lots of unhappy developers.
So how do you drive those values down? Use multiple updates to complete a feature. Use a separate update for the interface changes (and perhaps stubs to temporarily support them). Avoid the urge to put all of the changes for a feature in a single update; you know you’re going to need a couple more to fix issues you introduce anyway. Make sure your process allows you to check in features that are partially complete as long as they don’t break any functionality. If you drive these two numbers down significantly, you find a lot less file contention, and your product quality will improve.
Software CM metrics are not just useful, they’re also fun and interesting. They give you a better handle on what is really going on in your product development environment. If you want to follow up, take a look at a CMCrossroads article I wrote a while back on metrics and process maturity.
If nothing else, SCM metrics will enable your management and executive team to be more in touch with the need for good CM.
