How should we schedule bug-fixing?

In every project there will be new features and changes, and there will be fixing bugs.  Inevitably, the question will come up:

How should we schedule bug-fixing?

Key Considerations:

• Economic optimisation.  An optimal scheduling approach should be based on economics, that is, what maximises the value we get out of what we are doing.
• Detected bugs may only be symptoms.  When we first detect bugs, we're typically only detecting the symptoms of an underlying root cause or root causes.  These underlying defects may be causing additional undetected bugs or generating new ones.
• Predictability.  Bugs tend to be less predictable than other kinds of work because most of the effort is in exploring why the problem is occurring.

Solution Options:

• Bugs always get highest priority.  Always fixing bugs first is a very simple approach.  However, it may not be the economically optimal approach.  For example, fixing bugs on a rarely used feature vs adding a feature that will be heavily used.  For legacy systems with a lot of pre-existing bugs, this approach doesn't really work unless we modify it to be "new bugs always get highest priority".
• Bugs prioritised as just another work item.  If fixing the bug is more valuable than adding a new feature, then it's done first, if not, it isn't.  A typical problem with this approach is the tendency to underestimate the impact of not fixing bugs, especially with more complex systems.
• Fix bugs related to changes.  This strategy is more typical when there are a lot of pre-existing bugs. The general idea is that the most valuable fixes will be where changes are made and the incremental "bug fixing tax" is not that much given combined testing effort.
• Separate bug-fixers.  A number of people are reserved exclusively to investigate and fix bugs.  This may be a rotating role.  The specific number of people reserved reflects the economic value we place on fixing bugs vs adding features.

My Typical Suggestion:
In a greenfield situation, I would start with aggressively fixing bugs first but may move to prioritising them against other work items depending on the situation.  Keeping bug count very low helps a lot with predictability of required effort.

In a legacy situation with a lot of pre-existing bugs, I would use a combination of fixing bugs related to changes and prioritising bugs as just another work item.  If the team is large enough, I would also have people rotate through bug-fixing with an emphasis on root cause analysis.