The Economics of Perfect Software

An anonymous reader writes "This article takes the interesting perspective that leaving bugs in software is good — little ones, at least. This quote is particularly insightful: 'How do you know whether a bug is big or little? Think about who's going to hit it, and how mad they'll be when they do. If a user who goes through three levels of menus, opens an advanced configuration window, checks three checkboxes, and hits the 'A' key gets a weird error message for his trouble, that's a little bug. It's buried deep, and when the user hits it, he says 'huh,' clicks a button, and then goes on his merry way. If your program crashes on launch for a common setup, though, that's a big bug. Lots of people will hit it, and they will all be pissed. ... The cost of fixing all the bugs in your program and then being sure you fixed them all is way too high compared to the cost of having a few users hit some bugs they won't care about."

Re:Lets look at it another way

[Tablizer]

You cant afford perfect software.

Unless you are NASA:

http://www.fastcompany.com/magazine/06/writestuff.html [fastcompany.com]
     

The core argument does make sense.

[Max Romantschuk]

Sometimes it's better to ship a product and deliver it to 95% of the user base instead of having everyone wait because 5% wants feature X which is broken.

But there is the option to disable feature X, so rather than knowingly ship with bugs you can often have the program show a notice that this feature is disabled or something like that.

Generally when building software you'll have "Quickly", "Lots of features" and "Bug free". Depending on the software and project stage you'll want to strike a different balance. Releasing an alpha which has lots of features quickly with loads of bugs is OK. Releasing a final release of a program handling financial transactions with loads of bugs is never OK.

But yes, it's a question of economics, and what makes sense for a given project at a given time.

Obscure bugs can be fatal ones.

[Garrett Fox]

The post talks about minor bugs being the ones that are hard to reach, but that's not necessarily the case. There was a piece of radiation-beam hardware used for cancer treatment (the Therac-25 [wikipedia.org]), that became a case study in engineering because of a literally fatal flaw. It was possible to mis-configure the machine so that it struck the patient with a much more powerful radiation beam than was normally allowed. The relevant point was, this situation only happened if the operator did some obscure, seemingly unlikely combination of actions that would result in a lead plate getting misaligned or something. Yet it happened at least six times, killing at least two people. The fact that the bug was caused by this particular sequence of actions made it that much harder to identify -- and it was not a minor bug worth ignoring.