I know many of you are out there saying “*&% CM people, they never let us do X! And always slow us down!”
Take a deep breath and sit down for a minute and listen to me.
Most developers have heard of “DLL Hell” where an application compiled on one specific configuration of Windows doesn't work on any other due to DLL conflicts, version mismatches, etc. Most developers have said “It compiles on MY machine!” And finally there are impressive applications out there such as Maven which tracks all your jar files – the Java equivalent of a DLL – and will retrieve the specific version from online repositories. These are all symptoms of the same problem.
As a developer, our job is to make it work, end of story. On the first version or on a tight deadline, we don't always care how it works as long as it does work. We might code something that we'd never consider otherwise. We might hardcode a parameter, setting, or path. We might create an elaborate kludge that makes it work “for now” and we promise ourselves that we'll come back and fix it later.
Well, other issues come up, future deadlines aren't so far in the future, and we simply forget. So now there is this “short term” fix that makes it into the code repository or – worse yet – into production. From a Project Management standpoint these things become nightmares. This creates an entire series of little fixes or adjustments that have to be made for deployment or testing and every developer keeps the list in their head. This works fine for a single project, but now multiply this across every dependency, every other system your code interacts with, and every other developer on the project.
This is the cause of “DLL Hell,” “it compiles on MY machine,” and every other variation of this statement. As developers, we need to adopt some simple Configuration Management practices. If for no other reason, so we don't look like complete asses when we tell someone that “this works”.
So how do we fight this?
First, we must ensure that the development, demo, and production environments are identical. I know, I know, it's not always possible. Especially in the case of shrink wrapped apps, we must prepare a map of which different configurations we are supporting.
Next, we have to make use of automatic build tools. Apache Ant is the basis of this in the Java world, but there are a variety of tools in numerous other languages too. Most of these support features that will check the code out on a regular basis, attempt to compile it, and email the results to a specific set of people. The Pragmatic Programmers recently put out a book Pragmatic Project Automation that teaches you how to do this in the Java world. Buy it or don't buy it, but do it. These tools will detect these configuration variations closer to when they've happened and make them that much easier to resolve.
Finally, we must minimize our kludges. I know this is painful, but get over it. At the very least, we must move all these configuration kludges to a single place – preferably the Configuration File – and make them easier to adjust.
Is this full-blown Configuration Management? No, but it's the bare minimum you MUST have on project to have any chance of completing it.