So why would an ISV ever intentionally release a product with known bugs? Several reasons:
You release with known bugs because you care about quality so deeply that you know how to decide which bugs are acceptable and which ones are not.You release with known bugs because it is better to ship a product with a quality level that is known than to ship a product which is full of surprises waiting to happen.You release with bugs because the alternative is to fix them and risk introducing more bugs which are worse than the ones you have now.All of the reasons for such a decision are tied up in this one basic truth:
Every time you fix a bug, you risk introducing another one.
(Link: My life as a Code Economist)
Archive | bugs RSS feed for this section
My life as a Code Economist
December 19, 2010
0 Comments
The Economics of Perfect Software
March 29, 2010
0 Comments
Ergo, I propose the Golden Rules for Deciding When Your Software Is Ready for Prime Time. The Golden Rules state that you should keep testing your software and fixing bugs until the new bugs you find:
Aren’t embarrassing to your company.
Won’t tick off your customers.
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. The mindset here is not to use your customers as your testers — you’re bound to violate the golden rules if you do that — but rather to recognize that not all bugs are created equal, and some bugs justify not shipping a product while others don’t. Don’t be afraid to ship software with bugs. If you’ve got a good product that people want, a couple bugs won’t bother them at all, especially if updates to your product are easy to deploy, as they are with SaaS or a web application.
(Link: The Economics of Perfect Software)
