Commentary on The Art of Agile Development's Version Control practice.

There's a difference between version control and software configuration management (SCM). What's SCM, you ask? Well, the cynic in me says it's the price: version control systems (like CVS, SVN, Mercurial, and Git) are free; software configuration management systems (like Perforce, PVCS, and ClearCase) cost big bucks.

Don't get me wrong. I think it's important to be in control of exactly what software is deployed at any moment, to be able to roll it back in case of trouble, and to deploy only the features that are ready to be deployed. That's really what software configuration management is all about.

But the tools don't seem to be up to the task. Other than basic, plain-vanilla version control, real SCM requires that you manage interactions with third party components such as OS patches and library versions, database schemas, porting and back-porting data, and so forth. These require human judgment, which tools can't provide.

So instead, "SCM" systems are just glorified version control systems. They make up for their name and high price by putting "management controls" around version control, providing all kinds of admin controls to restrict who can do what, when. Sometimes they tack on bug and task trackers, too.

This "management" doesn't actually help you get closer to the goal of deploying and rolling back software; it just lets you play God with admin priviledges. One company used their SCM tool to enforce check-in comments. If you didn't provide at least a three-word comment with your check-in, it wouldn't go through. The most common check-in comment? "a a a." (The second-most common: "z z z.")

That's not management; it's paranoia and coercion... the opposite of good management. Real management is about hiring good people, giving them the resources and context they need, and trusting them to do their job. It's not forcing people to type in three words every time they check in. It's not linking every bug to a specific developer's check-in so you know who to blame.

Now, I'm no SCM expert and it's possible that I've missed something. But I'm going to take a risk here and shout the facts I see: the emperor has no clothes! The concept of SCM is important: we need to deploy software that works, incrementally deploy new features, and successfully roll back if something goes wrong, and we need to take our data with us in each direction. The sales job of SCM is an appeal to paranoia, control, and the hope that $30,000 of tooling can replace $100,000 of competent programmer.

It's the eternal dream: hope that tools and processes will substitute for individual judgment and expertise. Dream on.