The trouble with "High Priority"

[This is a long rambling rant -- you can stop reading now].

If you're bug tracking software lets you say that every single bug in the system is high-priority, then it's meaningless. You may as well say everything is low priority.

The answer isn't to have more granular priority levels (super urgent, semi urgent, sorta urgent and so on). To make a priority feature work you have to go holistic and look at the context of the bug...

Priority is so damn tricky and yet so simple:

Bugs doesn't exist in a vaccuum -- they exist alongisde other bugs/tasks and there are people who are going to do those bugs. If you're serious about settings the priorities for a series of bugs then you need to re-sort the bugs for a particular developer (possibly yourself).

"This one is the highest priority for Jack to work on, then that one, then that one."

You don't need to go down too low. A strict rank order is only useful for the first few. Assigning priorities to the lower order tasks is just 'busy work' that makes you look busy when you're really just shuffling papers. By the time those tasks rise to the top, other things will have come into the system anyway.

At Advantech Software (Brisbane's Premier .Net Consulting Specialists, ;-) we use FogBugz, from Joel Spolsky, and we're very happy with it. It's even begun to influence our language. We now say "I'll raise a foggy" anytime we either find a bug, or decide on a task, or invent a new feature.

But even fogBugz has the traditional 'priority' problem, much like every piece of bug tracking software I've ever used. Maybe a bumptop style solution would work? It's like the weather you know; everyone complains about it, but nobody gets in and fixes it.

Another feature I'd find useful is the ability to split one bug report into many bugs. And to split one feature into a series of tasks that make up that feature. Customers email in these documents that contain fifty different problems. And on a different track: simple features soon turn out to invole implemening many little steps along the way, each of which can be assigned to different people. (Let the bomb expert make the bomb, the safe cracker can crack the safe, the disguise expert can... and so on). This kind of hierarchy work quickly leads to usability problems. A feature rich interface can become impossible for any new user to pick up, and smart software does well to avoid it. An overly complex bug tracking system is worse than none at all.

Okay, just blogging this rather than emailing it to Joel Spolsky. Do you know he tends to personally respond to all his emails? I find that pretty amazing, as he's a busy guy. The technical support at technorati, by contrast is hopeless. How come they say I haven't updated my blog in 353 days when I update it every week? I've done the 'update ping' thing, but nothing works. If anyone can solve this for me I'll send them a robert scoble style link in gratitude.


I'm currently writing a book about how to build your first product. If you want to build your first product, please sign up to be notified when the book is available.

(By the way, I read every comment and often respond.)

Your comment, please?

Your Name
Your Url (optional)
Note: I may edit, reuse or delete your comment. Don't be mean.