Alan, you say “A majority of those bugs are introduced in fixes to other bugs -– and therefore by definition not caught by the automated unit tests” I’m not sure what you mean by that. I’ve found my unit tests to be invaluable in finding regressions caused by one-line bug fixes.

Also, you can use test driven development to fix bugs — write a test that fails because of the bug (in otherwords automate the reproduction of that bug) and then when you make that test pass — along with all your other tests — you can have reasonable confidence that the bug fix causes no other problems.

If you have a good set of tests, your risk calculation gets a lot easier. When all of your unit and functional tests pass there’s a good chance the bugfix you just checked in didn’t break anything else.

Sure, there is always some risk, but when you make the risk vanishingly small, bugfixes start feeling safe and easy — and that’s when life starts getting good. ;)

A majority of those bugs are introduced in fixes to other bugs–and therefore by definition not caught by the automated unit tests that generate those lovely green bars. Many times the offender is “an easy one-line fix”–add that to the list of lies. Often enough the new bug is worse than the one getting fixed. Sometimes the original problem is that someone changed the code logic without updating all the relevant comments, leading someone else to introduce bugs based on incorrect assumptions. These facts and others make every bug fix a calculated risk.

Tracking only 1000 bugs sounds like paradise to me.

The real issue isn’t tracking bugs, it’s deciding which ones will cause enough customer pain to be worth the risk of trying to fix them.