One of the most natural ways that build scripts decay is when you create create separate scripts for different configurations of your build. This typically does not happen when configuration just means “debug” or “release”. That’s usually handled quite well with compiler and/or linker flags, or just using command line parameters or other ways of modifying run-time behavior. I’m referring instead to different configurations that you actually ship to customers. Here at Fog Creek we have hosted FogBugz and Kiln as well as licensed FogBugz and Kiln. Other products might have both “lite” and “pro” editions. Or maybe you have a separate configuration of your product for each customer. Or you’ve got an internal app that needs to be a little different at each of the company offices.
The obvious problem with having separate build scripts for each configuration is that you then have to remember to change multiple scripts when something common to all of them changes. And the common stuff will change more than the differences will. When your scripts are used to build every configuration, then you know going into a change that you need to consider each configuration. For example, it may very well be that you’re making a change that will only affect “pro” users, but then you’ll remember that you need to properly disable the feature in the “lite” edition.
Like most cases of repeating yourself, it’s fine to do it once, to understand the differences, for example when you first add a new configuration. But then you should refactor, eliminating the repetition by using common build scripting technology. Whether you’re using msbuild, make, ant, maven, or whatever, it’s quite straightforward to have a single script deal with multiple different configurations of the build, even when fairly major differences arise between them. Often, the largest differences between configurations are not build-related but deployment-related. So if you’ve separated your build and deployment scripts you’re already halfway there.