Electricmonk

Ferry Boender

Programmer, DevOpper, Open Source enthusiast.

Blog

Bug priorities

Tuesday, February 22nd, 2005

Suppose there are two bugs in an application you’re writing:

One is a bug that is in everybody’s face. All of the testers have noticed it, and it has already been reported numerous times. The real end-users are bound to find it. However, it is a trivial bug and the behaviour it causes is easily circumvented by the user, once (s)he knows how. It causes no loss of data, but is merely a bug in the interfacing

The other is a bug in a rather obscure part of the application. The real end-users are not quite as likely to find the bug as with bug numero uno. In fact, none of the testers have yet found it, but you know it is there. This bug, however, is not as trivial and can cause a loss of entered data. Also, it can not easily be circumvented.

Which one to fix?

Well, both of course. But which one has the higher priority? Suppose there is only time to fix one of the two?

This may not seem like an important dicision, but I think it is. The decision you make will affect what users will think of the application in a profound way. Let’s look at some possible responses from users using the application:

Bug one: “Wow, this is an ugly interfacing bug! Golly, couldn’t they be bothered fixing something this obvious and trivial or what?”

Bug two: “Hmm, here I am in this obscure powerful part of the application and I’ve found a bug. Then again, I’m doing some pretty tricky and advanced stuff here which I’d normally only use once a month, so a bug here isn’t that strange”.

The funny thing is that the above two responses are how I would react as a user, but not how I’d react as a programmer. Loss of data seems much more severe then some easily avoided interfacing bug. But as a user I’d rather see bug one fixed.

Of course, this will not hold true for all data-loss bugs. In this case, bug one merely causes user-entered data not to be processed, which means they’ve just wasted about thirty seconds entering data. If, however, the bug were to cause a more severe data-loss (deleting data, for instance), to hell with what the user will think of the interfacing bug. ;-)

So, my lesson for the day is: When prioritizing bugs take in account the user experience and don’t just follow a programmer’s perspective.

The text of all posts on this blog, unless specificly mentioned otherwise, are licensed under this license.