Current Status

Offically Not Dead.

Branch Constraint Theory

Oh yeah, baby, I just invented a series of simple mathematical formulas that tells you why your project is taking so long to release, has so many bugs, and seems to show no signs of getting better. It might explain the weird many-way-branching of the Linux kernel and the annoying ever-slowing Debian release schedule, as well as (more importantly) some of the phenomena we've seen at work.

It's 28 pages of pure fun. I'll see about publicly releasing it if I can trim out the NITI-internal bits.

The most brilliant insight, which seems obvious once you read it but is quite non-obvious until then, is:

If you have two branches, a stable and an unstable branch, and you spend more time in code freeze than in feature addition, then each release will take longer than the last. That's because you start stabilizing the current "unstable" branch no sooner than you release the previous "stable" branch, so every feature addition phase is longer than the previous bug fixing phase. And if, within a release, your bug fixing phase is longer than your feature addition phase, well... it flies out of control, and you're doomed.

Doomed, that is, until you create MORE SIMULTANEOUS BRANCHES! And then you're differently doomed! Woo hoo!

Corrollary: simply adding more testing time at the end of a release cycle will not save you. And I'm now certain of it.

Oh, another interesting insight is that if you add features more slowly you can make more frequent releases. It's a fundamental law of software engineering and I proved it more-or-less mathematically. Go figure.

Update 2008/02/13: The link in the original article no longer works. You can find the Branch Constraint Theory PDF here instead.