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."
I know, that's too much to ask of modern code monkeys. How many of you who "good enough" quality have ever even read a book on "Software Engineering?" Have you even HEARD of the original NATO conference on that subject? How many have studied interesting "Software Physics." Yes, all code I write has bugs, because I am not omniscient. There are inputs and environments I never imagined the program having to cope with. But about half the code I write has two things rarely seen in code today: 1. Comments in the form of Assertions (e.g. "At this point, input XYZ is confirmed to be in the range 87...92". 2. About half the lines of actual code (absent comments) are validation of input conditions from the world (user and environment) outside the program itself. Perfection is not actually achievable, but IT'S THE ONLY TARGET WORTH PURSUING. Companies like Microsoft don't even try, because they're not in the software business; they're in the money-making business. Professionals care; money-grubbers aren't.