From the XpMailingList
There is no such thing as "no bugs". There is mean time between failure, either estimated or measured. The space shuttle software is supposed to fail less than once a century. Windows, apparently, is supposed to fail less than once an hour. I would be satisfied with MTBF of a month, and happy with a year.
"Zero defects" is a cop out for people who don't want to think hard about tradeoffs. --KentBeck
A kinder phrasing of this concept is "continuous improvement." Nothing is perfect, but things can always be made better.
Unless "tradeoffs" are a cop out for people who don't want to think hard about defects.
Okay, so there's no such thing as perfection. It's been said a thousand times before. Please complete the pattern. Since there's no such thing as no bugs, therefore ... (?)
... improvement is always possible. If improvement is always possible, we can avoid having "defect" witch hunts and CYA documents just in case an improvement is needed.
Oh, so a bug isn't really anything to get upset about, it's just an opportunity for improvement, and the more the merrier. SprinkleLoveOnTheSoftwareToMakeItGood?
, shall we?
This software is known to pass these tests. If these tests include your desired functionality, you can be reasonably assured that the software will work for your purposes.
Use an external testing company to provide an objective report.
Have an OnsiteCustomer
, who can provide valuable feedback to the team about the performance of the software. If the software is to be used by non-technical people, it is better that this internal tester not be a technical person.
I dunno. I'm pretty sure I can write a one-line program which has no bugs. (How about y'all ?) How about two lines ? Maybe I can make it three...
Well, it must break down somewhere. Where ? Kent suggests we think about tradeoffs - there's at least one involved, small and simple/no bugs vs. large and featureful/some or many bugs.
A friend of mind tells a story about a one-line module in an IBM operating system (which switched between the equivalent of user mode and kernel mode). It stayed as that one line for several years - then someone found it didn't do quite the right thing, and a bug report was raised. It ended up as a dozen lines or so. So, even a one line program can have non-trivial bugs!
Software is fragile, probably the most fragile artifact people have ever created. A single defective line of code in a million line system can render it unusable. So for the foreseeable future software will have defects -- GetOverIt
. The only way out seems to be to harness the re-usability of software. Write each X once (linked list, XML parser, etc), test the hell out of it, and then use it everywhere X is needed. IntentionalProgramming
was trying to do this. --IanRae