Tool time: Implementing configuration management, properly
Don't be a CM fashion victim
Configuration Management (CM) isn't just about IT, but in the space I have, I want to look at some issues around implementing an IT CM solution.
To start with, people often overlook the fact that IT is a fashion industry - but fashion isn't a very good driver for choosing tools that may be critical to your business.
The most fashionable Software Configuration Management (SCM) tool today is probably Git. Hey, Linus uses Git to manage the Linux kernel. If it can manage that, what can't it manage? Well, possibly, some things that aren't a UNIX kernel.
Don't get me wrong, Git is a fine tool and its distributed SCM approach is a very powerful idea. But there's probably a reason for Google adopting Perforce instead of Git. Probably because Google has a very much larger and more complex problem than Linux kernel development.
Ah, Google is the new internet king on the block, so shouldn't we all adopt Perforce then? Not necessarily. Perforce is a fine tool too, but choosing it just because Google uses it is simply another fashion decision. There probably aren't a lot of companies with requirements much like Google's, anyway.
Good tools are an important enabler for CM, but implementing CM, or SCM, should start with a management vision for what it can do for you; and with discussions about the requirements with all of the stakeholders. The SCM product programmers like, for example, may not suit games designers managing graphics assets for games.
Implementing any sort of CM process is a people thing and probably involves managing cultural change. Don't decide on a tool first. Choose a tool that enables the CM process that is best for you; once you've decided (again, emphasising discussion with all the stakeholders) what that is.
Then come up with a long list, cut it down to a short list and compare the best three tools, say, in pilot studies – and make sure you are in control of the pilot. If a vendor is in control, its tool will probably do fairly well on its pilot, regardless.
Then there's another anti-pattern to be aware of. Subversion, for example, is very popular with programmers and often installed under the covers, in place of a commercial "company standard" SCM tool.
Subversion is also an excellent tool - although the commercial support from Collabnet might be a good choice for a commercial operation. But how often is it chosen just because it's easily available? Most programmers hate being forced to use some tool a manager has told them to use, without consulting them.
All the SCM tools I've mentioned (and I could have mentioned many more) will suit the SCM, or CM, needs of some organisations - they are all "fit for (some) purpose". If you are implementing SCM your job is to find out whether they are fit for your purpose.
And never forget that the people who will use a tool really should be consulted during its selection. Programmers, for example, are very bright people on the whole. If they don't want to use a tool they think has been foisted on them by management, then they'll find ways not to. ®