Secret Origin of the ‘Super Ultra Critical Showstopper’ Bug

When you first start a project and you set up bug tracking software there tends to be 3 levels of bugs: Low, Medium, and High. After awhile you might notice there are now ‘critical’ bugs. Come back a little while later and there’ll be a ‘showstopper’ or ‘blocker’ bug level. And the funny thing is, most of the bugs will be logged at the highest levels. Literally 50% of bugs are given such a status as to make you think the app is in shambles. Except that when you actually open up qny of them to see what could possibly be so horrible, you find things like: missing fields, pages that should be pop-ups, and misspelled text. How is it that these things are given the highest level of importance?

Today, while I was working on a super ultra critical showstopper bug, I had some time to reflect on this phenomena. The bug was this: One of our models was missing a field. And the business wanted this field to be entered before the user could perform some task. Now, I should point out that nothing in the app was giving an error message, except that the user could get away without entering a field that had no functionality except to be displayed on the screen later. In my humble opinion, the app could have gone live without fixing this bug and nothing terrible would have happened.

But, you might say, it’s not my call to decide that. Absolutely right. But it’s also true that sitting next to it, at the same level of priority, were bugs that really were super ultra critical (such as the temporary inability to edit anything at all in our content management system – yipes!). So how do we let the business decide what gets done first but also have a rational system of ranking bugs? Well you need to have ranking system that actually means something. If high isn’t defined then everything gets rated as ‘high’ (especially cause manager X is gonna freak if it doesn’t get fixed – and every bug has a manager X) so we create ‘critical’ and then everyone calls things critical, and this continues until you have a very long list of bug ratings (and only the top two will ever get used). On a previous project we had the same problem and so moved to this rating system:

  • Priority 1: The app is down. No part of the app runs at all.
  • Priority 2: A large part of the app is not functional, but some parts still work.
  • Priority 3: An important function does not work, but there is a workaround.
  • Priority 4: Satellite functionality does not work.
  • Priority 5: Cosmetic change.

This worked pretty well: important things got fixed and if the client wanted to get something moved up in priority it could always be played as a card (like while technically misspelling the name of the application is a cosmetic change and therefore priority 5, but still…)

Comments

Matt McKnight said…
You have to have two fields- priority and severity.
In addition, we make sure we classify anything new as an enhancement or task versus a bug. Enhancement has no severity attached, and doesn't confuse when we try to take a metric oriented look at our quality.
April 24, 2007 at 3:24 PM
Post a Comment

Popular posts from this blog

What's a Good Flog Score?

I've been using Flog to measure the complexity of my Ruby code and I was wondering how others interpret Flog numbers. I'll go first with my opinions: Score of Means 0-10 Awesome 11-20 Good enough 21-40 Might need refactoring 41-60 Possible to justify 61-100 Danger 100-200 Whoop, whoop, whoop 200 + Someone please think of the children (note: these are scores for an individual method) The 20 - 60 range is interesting to me. Sometimes the complexity of what you're doing will justify the score and other times the method is in desperate need of refactoring. The highest Flog score I've seen in the wild was in the 300's. What's you're personal high and what do you think of my rankings? In other news, I've redesigned the look of my blog so if you only see my post through a reader you might want to stop on by, take a look, and tell me what you think.
Read more

SICP Wasn’t Written for You

The number of software luminaries who sing the praises of “ Structure and Interpretation of Computer Programs ” (referred to as SICP) is such a long list that you might think only a crazy person would take issue with it. However, to ignore SICP’s problems and continue to blindly recommend it seems just as crazy. SICP was the textbook for MIT’s introductory programming class and was a bit of a departure from other into to computer science textbooks at the time.  Wikipedia sums it up nicely:  “Before SICP, the introductory courses were almost always filled with learning the details of some programming language, while SICP focuses on finding general patterns from specific problems and building software tools that embody each pattern.”  Which sounds awesome, but does essentially say that abstract principles will be introduced before the nuts and bolts of a language.  If you think about that for a minute, you may see where the problems will be. When I was training to be a...
Read more

Point Inside a Polygon in Ruby

Recently my team needed to find out if a point was inside a given polygon and, as usual, we found some code on the internet that did what we wanted. And, as usual, there wasn't much explanation as to what it was doing. Here's the code (after we converted it to Ruby): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 def contains_point? (point) c = false i = -1 j = self .size - 1 while (i += 1 ) < self .size if (( self [i].y <= point.y && point.y < self [j].y) || ( self [j].y <= point.y && point.y < self [i].y)) if (point.x < ( self [j].x - self [i].x) * (point.y - self [i].y) / ( self [j].y - self [i].y) + self [i].x) c = !c end end j = i end return c end end So, you know, it works and I'm grateful to somebody for posting it but we had no idea how it works. So we wrapped 2 tests around it (one where the point is not in the polygon and another where it is...
Read more