Debuggability

Once in a while, you encounter a bug that's really, really hard to track down. The hardness depends on a lot of factors, such as the number of committers, complexity of the source base, number of temporal dependencies and the size of the changesets (here loosly defined as a commit.) How do you deal with these? The first step is to find the commit that brings disharmony to your project. If you don't use an SCM, you're basically FUBAR anyway and should leave this blog post immediately in order to get a clue.

One project that routinely faces all of these factors (and more) is the Linux project. It's a large project with fast-paced development, fairly complex code and a huge number of interactions and temporal dependencies. Because of this, the core developers have gotten really good a tracking down hard bugs (they tend to have a couple of super-hard-to-find bugs every other month or so.)

The awesome thing is that the techniques they've developed are equally useful for small projects, even one-person projects, as long as you have the discipline to maintain a debuggable project.

The magic words here are frequent commits, focused commits and bisection.

First of all, the best general technique to actually find the faulting commit is by bisection. Every modern source code management system supports it, either directly (such as git and mercurial) or by means of a third-party addon (such as Subversion.) Go Google it if you don't know what it is.

Frequent and focused commits means that, once you've found the commit that screws up your precious system, you'll have a fairly small change set to study and debug, and it will contain changes for a focused feature set with few interactions.