So, you’ve been using your favourite bug tracking system for years now. You do use bug-tracking software, right? I mean, you were right at the front of the class soaking up wisdom being dispensed a decade ago by a Mr Spolsky, right?

Phew, what a relief. 

Because I sure wouldn’t want my money held in a banking system that was built without bug tracking. Or, what if I was flying through airspace that was managed by a system cobbled together from lists in Excel spreadsheets? Holy bejesus, what if I got sick and ended up in a hospital that ran a dodgy IT system? One built by a vendor whose product manager only had a collection of Post-It notes of all those really important issues? Like the bug that confuses surgical operations for people admitted with the same surname on the same day?

Correctly using some form of bug tracking software is one of the most important steps toward improving the quality of software systems. 

However, after a while the traditional bug tracking approach starts to reach its limitations and a few problems start to emerge:

1. Triaging becomes increasingly difficult. With bug tracking alone, it is a bit of a black art to determine the severity of an issue or the importance of a new feature. Particularly when extremely vocal users are involved – of course their problem is of utmost importance to them, but is it representative of a large body of users suffering in silence? Without collecting data and making some measurements, how can you really be sure that you have correctly triaged an issue?
2. How can you encourage people to send feedback? Let’s imagine you are one of the users of your product. You are hammering the software like crazy – desperately trying to meet a deadline. Then –- bam. The application implodes. Right at the same time, your boss rolls in – “Hey Milton, are you done yet?” Arrrggggghhh! The people who built that particular application are not Milton’s favourite people at this point in time. In fact, Milton blames them for missing his deadline. Never mind that Milton has just spent the last two weeks browsing reddit. Do you really think Milton is in the right frame of mind to help you out by sending in a bug report? Are you really going to get the information you need out of Milton to make your software better?
3. Cruft collection. After a while you end up with a list of bugs and feature requests that have been sitting around for years. The sort of stuff you would really love to fix or add, but never really have the time, or maybe it is just too difficult to implement right now. Whatever the reason, there always seems to be more important things that need doing right now, and the cruft you collect becomes increasingly irrelevant and obscures the real issues facing your users today.

Here at UserMetrix we are exploring new ways to address these problems by helping you focus on the important stuff and get more out of your bug tracking system.