Guy Kawasaki has a funny and true to life list of the top ten lies engineers tell. But, almost as an asside he says:
Generally speaking, if the largest number of documented bugs doesn’t ever exceed 1,000, it means that the company isn’t tracking bugs carefully.
Which I think is crazy. Well, perhaps if you are Apple, or Adobe, or Microsoft, there’s some truth to this. But, my experience is that if you let the bug list get that high, on any 10 person project, you have a serious problem. Rather than spending time documenting bugs, spend time fixing them.
Your client isn’t paying you to track bugs, they are paying you to write software that works!
If you do test driven development you will fix lots of bugs at the moment of writing them. My experience is that the lower the time between when the bug is written and when it is found, the less time and energy are required to fix it, partly because you know where to look, and partly because the problem is still fresh in your memory.
If you are a manager, prioritize fixing bugs above creating new functionality.
If your boss walks in the door and says, we need feature X for customer Y, and it is your number one priority starting now, take a deep breath. And say, “That sounds great, but we have some important issues we need to take care of first in order to make sure that customers X, Y, Z, and A are all happy wth the quality of the software we deliver.” If you are afraid to do this, then get a better contact list and start lookign for other work, because standing up and taking responsibility to get bugs fixed is your job. Having other options in case your boss tosses you out on your ass, might make it easier to find the courage to do your job.
It may take courage to say no to new features until the curent defect problems are resolved, but you are the only one who can do it.
The more bugs you have, the harder they are to fix.
Ultimately, if your team isn’t fixing bugs faster than you create them, you face the very real possibility that your software project will be flooded. Eventually, your project could end up taking on new bugs faster than you can triage the existing problems, and you’ll sink just as sure as the Titanic once it started taking on water faster than the bilge pumps could bail it out.
“Quality is free,” doesn’t mean that it’s cheep, or that you can get quality without sustained effort. It just means that creating quality work, from the ground up — every single time, will actually save you money when you no longer have to pay for all the inspections, returns, and other costs that come from poor quality.
The same is true in Software Development. Ron Jeffries seems always asks “Why do you have so many bugs that you need a bug tracker? What’s wrong with your process?”
Toyota, when faced with defects, asks “how is our process broken?” and “How do we fix it so we don’t get this problem again.”
You’d be surprised what you can do when you treat bugs as quality problems that shouldn’t exist. You’ll definitely write more tests, and at first you’ll spend a lot more time fixing bugs. But if you manage to get it right, everything else in your whole system will go faster and more smoothly. And eventually, you’ll think the idea of tracking 1000 defects is insane too.