If you’re in compiled language, building object files, linking, installing, slamming a WAR [Java web archive] file somewhere or a JAR [Java archive] file somewhere else or whatever your particular platform demands -- however you actually construct and deploy the software needs to be completely automated and those instructions for that automation need to likewise be under version control so that there’s really nothing left to chance.
The production process is ironclad and subject to version control. The unit tests are fairly complete so you can test anything that you’ve introduced for good or for bad, and it may be acceptable. You may decide to change things as a result of it, but at least you know if you’ve introduced anything that makes a material change to the functioning of the software.
With these three low-level technical practices in place, it’s pretty safe to do almost anything to the code base. You can optimize it for speed. You can add functionality, remove outdated functionality, change things depending on changing business needs, refactor the design, because now you’ve got to hand it over to maintenance programmers who aren’t as up-to-date on the techniques you used originally.
Ed: Speaking of maintenance programmers, how do you hone your sense of smell for where a bug might be?
Andy: The best place to look for where a bug might be is quite near the last one you found. That’s my number one tip. You can look this up in the ACM papers—there are studies that show bugs tend to clump. [They’re] not uniformly distributed at all. They come in clumps. So when you’re doing code review of other people’s code or you find something you did horribly wrong, the odds are pretty high it’s not sitting there by itself and it’s gonna have something else real nearby. So that’s always a good starting point.
Ed: Assuming they’ve already tried that and it didn’t work, do you have any advice to help people track down hard-to-find bugs?