In another post, I claimed that software can’t be written with no bugs at all. Well, it turns out that’s not quite true. What I shouldhave said is that writing bug-free software is not possible within the constraints of most software businesses or open-source projects.
But that just doesn’t have the same pizazz, does it?
The trouble is that software businesses exist to make money, and open source projects exist to give developers interesting things to do and exposure. (Naturally, there are some exceptions in both camps, but if you imagine that’s always true, you won’t be too far off.) And if these are the goals you’re chasing — customers and money, or interesting problems and exposure — you don’t end up with perfect software. You go broke or get bored before you get there.
Hence, perfect software can only be written by a few unusual organizations. And of these few unusual organizations, few write perfect software at all, and among those that have written perfect software, few of them do it all the time. So, while perfect software is not a never kind of thing, it is a few ^ 3 = really ?*#$%@! rare kind of thing. Fortunately, though, there are a few examples we can look at.
Take qmail and djbdns, for instance. Both programs are written by one guy, Dan Bernstein, who is an absolute security fiend. (I think he has a Bruce Schneier poster on the ceiling over his bed.) He wrote both of these programs from the ground up to be perfect and secure, and it’s hard to say he didn’t succeed: the two projects have had about ten (minor) bugs between them and zero security bugs since djbdns was introduced in 1991. If you’re not from the software world, that is an absolutely extraordinaryachievement for open-source software that is as widely used and well-scrutinized as qmail and djbdns are. (Now I’m sure he has a Bruce Schneier poster over his bed.)
But note how unusual the qmail and djbdns “team” is, though. Bernstein wrote these programs alone, which means everyone working on the project knows exactly how everything works and exactly what’s going on at all times. This eliminates communication errors and the bugs those errors cause. Of course, it doesn’t hurt that the whole team is made up of damn fine, highly motivated, security-oriented coder(s), either. Maybe most important, though, both programs were written for academicreasons on an essentially unlimited development schedule. (He’s also incredibly dedicated crazy — he famously said that he won’t be satisfied until he’s put the entire security industry out of work — but I’m not convinced that being a little crazy doesn’t actually help with writing good software.)
Each of these factors is critical to the quality of qmail and djbdns. Without all of these elements — a dedicated team of excellent programmers, working closely together, with a primary goal of perfection, in a liberal development environment — qmail and djbdns wouldn’t be perfect. And I’m pretty comfortable claiming that such an environment exists nowhere in the business setting.
If you know differently, are you taking applications?
There is, however, another good example of such an environment in government, of all places. NASA’s DPS, better known as “the Software that Runs the Space Shuttle,” is another good example of perfect software.
It’s easy to see why the software controlling the Space Shuttle is perfect: it has to be. It controls a $1.7 billion dollar machine that was motivated by a Presidential declaration and travels at thousands of miles per hour on international television. (Oh, and it’s responsible for the safety of 6 of the nation’s greatest minds at any given time. So there’s that, too.) Perfection is not a goal here, it’s a requirement.
Exactly how perfect is it? A good Fast Copmany article about DPS says it well:
What makes [DPS] remarkable is how well [it] works. This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats : the last three versions of the program — each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors.
So, pretty damn perfect.
How’d they do it? Both the development process and the team used to build DPS have been the subject of several studies and articles, and the consensus is that they’re both pretty unusual.
The team is comprised of 260 Lockheed Martin employees in Clear Lake, Texas who have been hand-selected specifically for their ability to write complex software correctly. These people are the best of the best of the best (sir!). (Contrast this with the quality of your average amateur web developer. It’s amazing that someone hasn’t accidentally the whole internet yet.)
The process is unusual because hitting milestones and delivering on schedule is not the highest priority, eliminating bugs is. For NASA, if they’re not sure the Space Shuttle launch will be perfect, the launch doesn’t happen. That’s exactly the right attitude for writing perfect software. The team is also unusually well-funded, with an annual budget of $35 million to maintain a 420,000-line codebase. So you could cover your kid’s tuition for 4 years of public, in-state university education on 120 lines of this program.
But the most critical difference between other software and DPS is much simpler: purpose. DPS does not exist to make money; it exists to land people on the ?*#$%@! moon. Just as an exercise, think about the mindset you’d have if you worked on sending men to the moon as opposed to Microsoft Word. (I’ll wait while your brain explodes.)
Does all this sound familiar? We find the same elements here as we found in DJB’s projects: a dedicated team of excellent programmers, working closely together, with a primary goal of perfection, in a liberal development environment. It’s like a themeor something.
But the really important takeaway from these examples is that none of these programs has “making money,” “marketing myself,” or even “doing interesting work” on its list of goals. For these projects, “making perfect software” is the only goal even on the radar. It is this observation that has led me to formulate The Golden Rules of How Not To Write Perfect Software:
- Put “writing perfect software” anywhere but first on your list of goals
- Put “making money,” “doing interesting work,” or “marketing myself” anywhere on that list
If you do either of these things, you’re guaranteed not to write perfect software. If perfection is not the first-order goal, or if self-interest is a goal on a project at any level, then diminishing returns will always result in software that is not perfect. Perfect software isn’t something you achieve by side-effect while pursuing other goals. Perfect software is something you can only achieve by pursuing perfect software.
And on that note, I’ll leave you with one more thought on the subject from the Godfather of Computer Science:
Software is hard.
— Donald Knuth
Rock on, Dr. Knuth. Rock on.