The following is a post I wrote for my UserMetrix project (a tool for software developers):
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. 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 stepstoward 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:
- Triaging becomes increasingly difficult. With bug tracking alone, it is a bit of a black art determining 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?
- 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?
- 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.
Comments:
You can join the conversation on Twitter or Instagram
Become a Patreon to get early and behind-the-scenes access along with email notifications for each new post.
Hi! Subconsciously you already know this, but let's make it obvious. Hopefully this article was helpful. You might also find yourself following a link to Amazon to learn more about parts or equipment. If you end up placing an order, I make a couple of dollarydoos. We aren't talking a rapper lifestyle of supercars and yachts, but it does help pay for the stuff you see here. So to everyone that supports this place - thank you.