People who know more about software development processes than me, and write books on the subject, frequently talk about metrics like Defect Density (defects per thousand lines of code). Say your development team averages 10 D/KLOC. If you start working on the next version of a product with 1M LOC and eventually add 100K LOC, you could look into your crystal ball and expect 1K defects. Holy crap! Honestly, it could be worse. In my experience, adding code to a 1M line product is likely to break lots of the existing code as well.
What if you start a product completely from scratch and end up with 1M LOC? 10K defects could give the faint of heart a reason to jump out a window. How will you ever know when to ship your product? I have written enough code in various products for various companies to know that those people writing those books know what they’re talking about. I have seen it work out just like they predicted it would. Bad things happen to new code. I have come to expect it.
Sometimes people, usually pointy-haired types, get really caught up in things like defect counts. It drives me nuts. Defects are a fact of life in software development. You need to document and prioritize the defects discovered in your products. When it gets close to ship time, look at a cost benefit analysis of each defect. Compare the cost to fix to the cost of leaving it in the product. At some point, you will have to ship your product. It will have defects in it. Knowing what they are is a Good Thing. Making sure the bad ones were fixed is a Good Thing.
Joel On Software has a good article on the cost of fixing defects. Steve McConnell also has some good articles about when a product is ready to ship. They apply some rational thinking and decision making, instead of simply the “fix all bugs!” or “zero defect!” mantra pointy-haired types like to spout.