The Economics of Perfect Software 201
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 (Score:5, Interesting)
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.
Re:How is this news? (Score:4, Interesting)
Diminishing returns applies to programming too... big surprise...
But you don't know how much each bug will cost. What if that little UI glitch gives remote root?
BTW Joel Spolsky [joelonsoftware.com] said the same in 2001. Big fucking news indeed.
My TV Remote has bugs... (Score:2, Interesting)
If I connect my TV remote to the mains AC, it will break. I blame the makers for not 'validating' my input voltage. My Cups/Mugs all have bugs, as when I drop them, they break....silly makers for not designing in dampers to cushion the blow. My car has bugs.... I can very easily crash it, how dare the manufacturers make something I can crash by just pressing the buttons/ turning the wheel in the wrong order.
My point is, that practically everything will fail, or demonstrate unpredictable behavior if it is subject to conditions to which it is not designed to handle. We accept this, as a fact of life!....Why should software be judged any different, just because it's 'virtual' and cant really be seen as a real world object?...to make a perfect bug free piece of software is practically impossible.....well, maybe 'hello world', and even this will fail should it be run on an architecture it was not designed to run on.
Re:How is this news? (Score:5, Interesting)
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.
Re:Oh Please (Score:3, Interesting)
The other thing that might be a possibility... is that software needs to have bugs from the business end to ensure lucrative service contracts.
Now this is just pure speculation of course... but I used to a work for networking vendor known for superior customer support... and making mega bugs in the servicing contracts as well.
I sat there looking at some ridiculous policies in the software realm that almost seemed to encourage bugs in the code as opposed to writing good software.
They were throwing code around to various teams... seemed to value programmers who could be tossed onto a project instead of those who wrote good software...
I left... not my kind of place... I don't like being a janitor cleaning up everything... but lately... I've gone more into technical project management. You know what customers love... they love seeing lots of engineers giving them attention.
So it got me thinking if such policies to encourage buggy software are not just stupid policies, but actually active management policies... to ensure customers are willing to pay for lofty service contracts.
Get something that works reasonably well to get things working... but make sure the bug fixing phase never ends... and you never lose service contracts.
You never just sell a piece of hardware... like a spoon.
Re:triaging incompetence (Score:3, Interesting)
The economic angle is a dangerous meme, because it lets incompetent management off the hook by allowing them to triage incompetence, and in particular, to ignore process failures, and the failure of team culture, both of which point back to management itself. We all know how well that worked out for NASA. This wasn't fixed until lives were lost.
If you're writing code for NASA, or say the medical industry, I'd agree. But 99.9% of the developers out their are writing code that nobody is ever going to die because of a bug. If you tried to apply the same standards to business software that you do to Nasa or medical software, nothing would ever get done.
As far as a "culture of incompetence" is concerned, and triaging bugs, I don't see the two as terribly connected. There's always going to be bugs, and some of them are going to be minor. This will happen even if you have the best developers in the world. Accepting bugs doesn't mean you give up on quality, or don't look to improve your process. It can actually be PART of that process. You assume all bugs come from "incompetence" or "process failure", or something wrong with the system. That's just silly. People aren't perfect. Hell, machines aren't perfect. The perfect is the enemy of the good, as the saying goes.