The other day I was trying to get one of our build scripts at work to run on a new build machine we’d brought up. Because all of our build scripts haven’t been actively maintained, they are very much tied to the environment and other hard dependencies of the existing build machine. And so getting them to work somewhere else (without modifying the script) involves a lot of work to setup all of these hard dependencies. It’s good for me to do this so I can get a better understanding of everything our build scripts do, and why they do those things, and what could reasonably be changed.
Anyway, so in this process I got to a step that was failing in the new build machine. It was trying to access an internal Subversion server for some files, but the new machine could not see the server because of our network configuration. Changing the network configuration wasn’t really an option, so at a bare minimum we’d have to make changes to the build script. After puzzling over it for a little while I finally realized that the step in question is no longer used or relevant at all (you probably guessed that when I mentioned Subversion, since we offer a competing product). It might as well be a no-op. Even better, the same step had caused failures on the official build machine in the past, failures which I worked with our system administrator to fix, so that our builds wouldn’t be broken. But we could have just as easily removed the failing step, instead of continuing to maintain rotting script code.
It was humbling to realize I hadn’t found this issue when it broke on the official build machine. But it also made me realize that build scripts must be actively maintained. If they are not, they will rot. When they do, you’ll get random build failures at the most inopportune times, and you won’t have confidence in the fix, or even if the fix is necessary.
In this particular case, it would be easy to fix it (by removing the dead code) and make no other changes to our process. Fixing it will certainly happen. But we really need to “fix it twice”, by going to the root cause and fixing that issue. The clearest way to do that, in our current situation, is to move forward with a plan I already have - to refactor and combine our build scripts so that developers use the same scripts as the official build machine. Once that happens, we can move ownership of the build scripts back to the development team. Because they will no longer be tied to just one “official” build machine, they’ll naturally be fixed and cleaned up by the developers who use them on a daily basis to get their work done. As build manager, I’ll just need to make sure the scripts still work on the build machine.