Wednesday, 21 May 2008

Raising the bar on bug priorities

Inevitably during the course of writing an application, bugs creep in. And like all good software teams we diligently capture them, along with some priority level. Let's say for the purposes of discussion the priority levels are: trivial, minor, major and critical. Fine. So far, so good. But, as time goes by and bugs get raised and some get fixed, the way in which priorities are determined seems to change. If the entire bug queue does not get cleared out regularly, what was minor before starts to become major because the people raising the bugs know that it will be fixed sooner. The result is that most of the bugs tend to land up in the next-from-top priority level (major) and before long the lower ones (trivial and minor) become little more than an afterthought. The highest priority level (critical) is usually spared as it is those bugs that really are showstoppers that still fill this priority level. It's not uncommon for a new priority level to suddenly be introduced to start separating the major bugs out into the more major and the less major bugs. This sets a dangerous precedent - what's next: Even more major? Almost critical? Aargh..

This seems to be a fairly common problem, seen in many organisations, on teams of varying sizes. As I see it, some of the root causes are:

  • Letting the bug queue grow too big
  • Not defining exactly what is meant by each priority level
  • Having too many stakeholders. Whose priority is more important?
  • Complexity or difficulty in fixing a bug are not interchangeable with priority - just because a bug has a priority level of 'trivial' it doesn't mean it will be quick to fix; and vice-versa.


Simon Brunning said...

severity inflation. Know it well.

Simon B.
GTalk: simon.brunning | MSN: small_values | Yahoo: smallvalues | Twitter: brunns

Bladerunner20 said...

Of course they want open source. Try find a univerisity grad willing to work in public sector SA that really "gets" OO. Or athything else for that matter. Like maybe, Identity Federation. Or application firewalls like IAG or Juniper. Try asking someone the diffrence between bounded and un-bounded iteration loops. When you have to push x people through university to meed affirmative action quotas open source is an obvious short term solution that hides long term deficiencies. Which is why first there was white power, then there was black power, and now there is no power.

Bladerunner20 said...

Thins thing has a bug. When I logged in it posted the above comment against this older post. Wouldn't happen on a .NET platform ;-)

Bladerunner20 said...

Ok, so I've read this post, and have something to say to this one too - the project team (dev and test) should have a triage process the drives resolution based on impact (risk * severity), and a vote. Capter 8 (My Way or the Highway - Negotiation) in I.M. Wright's "Hard Code" has some interesting view.

mpatric said...

Bladerunner20 - sure, triage determines which defects to fix first, but it doesn't stop the inflation effect. Risk and severity are both relative (to what's already in the queue).

Stephen said...

When everything is a priority, nothing is a priority.