All Bugs Are Not Equal

Unless you are writing safety-critical software (and even if you are) it pays to get a sense of proportion about the potential impact of bugs you uncover.

Rate all your bugs by how likely and frequently they are to occur, how much impact they would have if they did occur, and how much time and effort it would take to fix them.

Then ReduceUnimportantInformation and discard the ones that score low on all scales!

"Discard" may not be the right term. It usually makes sense to keep bug reports, and not to throw them away. But it certainly makes sense to not try to fix every single bug, and to categorize such bugs as "rejected", "on hold", etc.

An important concept is triage. Separate bugs into three categories: those that absolutely must be fixed for the system to have value for customers, those that you would really like to fix if you have time/budget, and those that aren't worth fixing. Work on only the bugs in that first category, until it is empty. Devote resources to bugs in the second category as importance, time, and budget dictate. Don't do any work at all on bugs in the third category.

Some of the lower-priority bugs may be easy to fix, but resist the temptation to fix them. Over the course of the project, changes may occur that make those bugs irrelevant, so any time spent fixing them is wasted. Developers may FixBrokenWindows in the course of making other changes. Don't officially assign anyone the task of fixing unimportant bugs--there is something more important that person should be doing.

Actually, I organize all of my work by triage. There are always many worthwhile tasks to spend my time on: fixing bugs, adding new features, improving the documentation, creating tests, refactoring code, etc. I decide which tasks add the most value per unit of effort, and focus on those tasks.

Consequently, I almost always complete the crucial tasks on time. When things are less busy, I tackle the lower-priority tasks. -- JaredLevy

I do the same - triage. The way I do it is a bit different - I divide the work into:

coding correct functionality
adding bugs to it

then I do the important part of that. Of course, as with any problem of task breakdown, this occasionally fails to divide finely enough, and I find myself faced with the task of removing the bugs I've put into my code. Accordingly, I triage according to three categories, ranked by importance:

reflecting on how to accurately tell "correct" from "buggy"
coding correct functionality
adding bugs to it

the latter category very rarely making it into my radar scope, except occasionally when I choose to give in to some pressure or other, usually management pressure. -- LaurentBossavit

I used to work in a shop that didn't truly believe in bug triage, even though it was otherwise pretty well run.

The tracking system could categorize bugs as "Closed", "Open", or "Not A Bug". Or something like that. But we also had a policy of shipping only when all bugs were resolved! As a result, bugs that should have been put into the "Deferred" category were marked "Closed" instead. We were bug-free by definition!

It would have made much more sense to maintain a "Deferred" category for those bugs that are important enough to be noted but not important enough to hold up a release. -- MarkSchumann

Above, where the triage system is described, it says this: Separate bugs into three categories: those that absolutely must be fixed for the system to have value for customers, those that you would really like to fix if you have time/budget, and those that aren't worth fixing. I can believe in this general system, but I can't believe in the concept of a bug not worth fixing. I can believe that it may not be worth it to fix a bug in time for a particular release, but I don't think any bug should ever sit on the bottom of the priority queue for years, from release to release, unless it's difficult to fix. Users really hate it when they find that version 7.0 still has a bug that version 1.0 had.

Also, what might be a niggling detail to the developers might be infuriating to some users. For example, just this morning I had my virus scanner pop up a window that stole the focus without my permission, and I ended up hitting a key and making it almost cancel the operation it was doing (luckily it popped up a box asking if I was sure first). It only does this once a morning, and some people don't care about this sort of thing, so if I submit this as a bug and the developers are using the triage system, they might chuckle and put it on priority 3 in their bug list, if they don't throw the report away outright. However, to me it's more of a priority 2, and to some people it could even be a priority 1 if they get annoyed by it every single morning. - Kef Schecter (FurryKef)