15 Bugs

Summary: Teenagers can learn only from their own mistakes. That seems true for a lot of software types, too.

According to http://www.ecrmguide.com/article.php/3927666/drupal-8-open-source-cms-starts-to-take-shape.htm a content management system named Drupal has, in the past, experienced severe delivery delays due to bug infestations. For the latest version developers promise that there will never be more than 15 critical bugs at a time, so they can "do timely releases because we know at most the release is only 15 critical bugs away from being ready."

Capers Jones studied 4000 late software projects and discovered that bugs are the biggest cause of late deliveries. For this and other reasons, I advocate - in general - getting rid of the bug list. Don't accumulate defects; fix them when they appear. No one knows how long it'll take to fix a problem, so a substantial bug list means there is no schedule.

We've known for a generation that bugs are schedule-killers, so I find it interesting that the Drupal developers had to discover this fact through the agony of failure, rather than from research, book learning, or the wisdom passed down through mentors. Though I congratulate them on learning from their own mistakes, the process reminds me of raising teenagers. The most frustrating part of guiding young `uns through those tough years is that they are utterly unable to learn anything from someone else's experience (unless it's an incorrect lesson garnered from an equally-misinformed friend). Eventually, though, they do grow up and realize that the old fogies do know a thing or two.

As Mark Twain said, "When I was a boy of fourteen, my father was so ignorant I could hardly stand to have the old man around. But when I got to be twenty-one, I was astonished by how much he'd learned in seven years."

Maybe we software people are teenagers!

Is it even worse than that? I find very few firmware groups make any effort to systematically learn from even their own experiences. The retrospective (AKA postmortem) is well-developed and widely taught, but rarely practiced. The idea is to take a little time at the end of a project and try to understand what went wrong, and then invent solutions. One would think that we engineers, who love problem solving, would find this a natural and compelling thing to do. But we don't. Most groups don't even make much of an attempt to codify knowledge, say via the disciplined use of a wiki. Since we were late, the next project is already behind schedule, so there's no time to think about ways to improve.

We're bailing as the boat sinks, instead of plugging the leak. She's going down, folks - it's just a matter of when.

Published March 11, 2011