Skip to content


Triage

Eric Sink is a software developer at SourceGear. He’s written a terrific essay, My life as a Code Economist, that describes the software bug triage process. The term “triage” was borrowed from medical triage where a doctor or nurse has to prioritize care for a large group of injured people. The main job of a software bug triage team is to decide which bugs need to be fixed (or conversely, which bugs we’re willing to ship with).

Eric lists four questions that need to be answered during triage to decide whether a bug should be fixed or not:

  1. Severity: When this bug happens, how bad is the impact?
  2. Frequency: How often does this bug happen?
  3. Cost: How much effort would be required to fix this bug?
  4. Risk: What is the risk of fixing this bug?

The answers to these questions determines the bug’s priority which indicates whether a bug must, should or won’t be fixed. The priority determines which bugs the developers will work on and when. High priority “Must Fix” bugs should be fixed first.

As Eric says, the first two questions are about the importance of fixing a bug where the last two are about the tradeoffs involved in fixing it. Developers sometimes focus too much on the cost of fixing a bug independently of its importance. The justification is often “to clear out my bug queue”. This is a bad approach. Important bugs should be fixed first. Unimportant bugs should always be candidates to be deferred. (As we used to say during triage, paraphrasing a Homer Simpson neologism: De fer, the two sweetest words in the English language).

As a project’s ship date approaches, the triage bar gets higher. It gets much harder to get the triage team to approve a bug to be fixed. Lots of bugs are deferred. The goal is to reach “zero bugs”. This doesn’t mean that the software is defect-free but that all known bugs have been deferred or can be rationalized away in some other way. At IBM we called this date “Virtual Zero”. At Microsoft, this is known as Zero Bug Bounce (ZBB) day.

Posted in Uncategorized.


One Response

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. John Gruber says

    > Risk: What is the risk of fixing this bug?

    I like to ask the opposite question: what is the risk of *not* fixing this bug?



Some HTML is OK

or, reply to this post via trackback.