Prioritising bugs

30 May 2019

The priority for fixing a bug should be a function of several things:

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

Two of them are "user questions" (Severity and Frequency), and the other two are "developer questions"  (Cost and Risk). Questions 1 and 2 are about the importance of fixing a bug. The answers to Questions 3 and 4 can only make the priority of a bug go down, never up. If the answers to 1 and 2 make it obvious that a bug doesn’t deserve attention, then questions 3 and 4 don’t need to be asked – they are just there for when the first two questions come out with "need to fix this".

A crash is obviously very severe, no matter what the cause. If you lose data because of the crash, that makes it even worse. But I can think of things worse that than that, such as giving the wrong result to some calculation. If a crash happens on a limited set of data, that reduces the frequency of it – so a crash that happens every time you do X is more imporant than crash that happens every time you do X with data Y.