Slashdot Mirror
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."
Quote from the site:
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.
So yes, they have errors too and their software isn't perfect nor bug-free. But their acceptable cost versus bug-free threshold is just a lot more higher than usual software. Exactly what the summary and article is about.
yeah, there's a also a mistaken suggestion that there's a correlation between the severity of the bug and the cost of fixing it.
in general there isn't.
you might have a crashing, data-destroying bug that's trivial to fix. or you might have a minor UI annoyance that would require a complete re-write in order to fix, possibly introducing a whole slew of new bugs.
unless you have a deep understanding of the architecture of the application, there's absolutely no way to judge which class a given bug is in.