Bug Free Up Front

But seriously, folks, an absolute 0 bug count might indicate your detector is broken. And >never< underestimate the value of a HairyArm!

Discussion moved from SheChangeDesignInTheDatabase.

I've written software that was completely bug free upon initial delivery to the customer. It is possible. There are several basic rules for doing so, which basically combine the XP way of doing things with the mathematical formal proof system that EwDijkstra espouses:

Test First By Intention (from XP)
Write Code So Simple It Has To Work (from Forth; related to formal proofs)
Test Only What Can Break (from XP)
Factor, factor, factor! (from formal proofs, XP, and Forth)

By doing this, I've written programs which have fulfilled their requirements without any additional side effects first time. It's hard to do, and takes practice. But when you've been using these rules in conjunction with each other for years and years and years, you'll find that it's possible to write even non-trivial code so that it works first-time every time.

-- SamuelFalvo?

How long does it take and how much does it cost? What metrics did you have to determine "bug-free"?

It's interesting to me that ForthLanguage is mentioned above in conjunction with bug-free software. I've found that my Forth programs are a lot less buggy than the programs I write in other languages, and I've had the surprising experience of writing some non-trivial Forth programs that ran as expected the first time. I don't know why this is, but my theory is that Forth forces some kind of discipline on you that other languages don't. I wish I knew what it was, so that I could apply that same discipline to other programming languages. -- KrisJohnson

I really wish to believe this is possible. But IME, there are always holes in the requirement (i.e. there are always input into your program for which the "correct" behaviour is not defined), and these holes always turn into "bugs" when the user find them out. -- OliverChung

I know of a handful of business projects whose defect rates in the field are less than one per month (where a typical project of similar scope would have tens or hundreds of defects per month). It is possible, and it takes less time than the old buggy way once you learn the techniques. -- KentBeck

Are those projects done in XP style or more traditional waterfall? If the latter, can you tell us how long did the user requirement phase took, timewise, from just a rough concept to the final document, relative to the whole period of the project?

For projects I did/doing, the ratio is usually <20%, sometimes only 5% (those customers are really just asking for trouble, they got what they asked for in the end.) I frequently have to work with clients where even simple yes/no clarification may takes days and a few escalations to get answered (sometimes not at all). Either they that just don't bother to think about what they want, or they just want to "reserve the right" to change their mind later...

Client: "I never said I want it this way, I want it the other way!" - 1 bug logged
Me: "Uh... I asked you which way you want it done x times already, you just never answered..."

-- OliverChung

The above dialog smacks of making stuff up - if it's a bug because the customer won't say what they want, then you can't really proceed on that bit of the program. At most, you have a stub that gripes about the question.

-- IanKjos

I've been part of several (4 or 5 depending on how you count) XP projects so far (since 2002). They went much faster than anything I had experienced before that. They also had bug counts that were at least 10X lower than anything I had experienced previously. Our first XP project delivered to production and then counted three bugs (one real bug and two very simple cosmetic issues) pretty quickly within a month and then no bugs for another three months. The next release delivered with one bug and ran for another three months. That project later had quick one-month no-bug releases. After that, we did other XP projects that delivered very quickly with very low bug counts (on the order of one/month or less). It is definitely possible to "approach" zero bugs and to change our mindset to "not expect bugs" rather than the old mindset of expecting bugs.

-- MikeCorum

There seems to be some confusion about what a bug is; a requirements change is not a bug--a programming error is a bug. A bug is failing to deliver what was intended.

There are lots of bug-free programs out there and lots of programmers who routinely deliver them. My house and car are full of gadgets run by software that does exactly what the manual says it should do. I've run a half-dozen projects that produced zero bug reports in their operating lifetime. A couple had to be that way because bugs could kill people. There's no way to prove they were bug-free, but the signs are good. All but two involved teams of relatively junior programmers. They were distinguishable from the usual run of programmers in two important ways: They were neat-freaks, and they knew how much--and how little--they knew.

-- MarcThibault

Possibly related to TheyUnderstoodMe / BugFreeSoftware / CategoryQuality

CategoryBug