Ian Landsman with his quick idea about bug tracking triggered a little discussion about the subject. Why we have a problem with tons of bugs/feature stored in bug trackers? Why ideas like throwing out a bug tracker appears? Why we’re advised to leave feature requests tracking at all?
I think the problem lies not within bad, bad bug trackers which become bins storing everything. I think the problem lays in the way we use bug trackers. If your bugs database is cluttered it’s most likely not the fault of application itself.
Why bug trackers become cluttered?
• Organization. You need versions, application modules, priorities, submission states etc. You need people responsible for every bug or feature request. Although it looks fairly easy from the perspective of a single bug, it’s much tougher when you look at all that mess after 2 years for 3 applications (4 versions and 6 modules each) with staff rotation and strategic reorganization introduced by the board because it’s more than a year since the last one. The rules should be clear for everyone. When there are too many submissions with “critical” priority it’s either people overusing it or you have a problem with your product, not the bug tracker. When single person has more bugs that he can grasp it means that they’re either poorly organized or you have a problem with your product, not the bug tracker. When you submit issues only for the sake of submitting them not planning to do anything with them it’s either problem with people’s responsibility or (you won’t guess) you have a problem with your product.
• Cleaning. The bigger the issues database is the more you need to clean it once in a while. Review feature requests which are attributed to future versions in case they’re already done or become obsolete. Yes, it is an additional effort, but you don’t leave cleaning your house only because it’s additional effort. If you do, you shouldn’t at least moan that the house is a bit messy. Another thing here is moving things you know you won’t do in the very version to future ones as soon as you can. Leaving them on developers’ dashboards won’t help you much anyway. Adjusting original priorities is also the part of the work here.
I think that well-organized suitable bug tracker isn’t an option. It’s a must-have. And of course a suitable bug tracker can mean different application depending on a product, team etc. For one of my projects free version of simple 16bugs works well. On the other hand I know teams that use fully-blown Visual Studio Team System installation, including issues tracking of course. One of the best tracking applications I’ve seen was developed in-house – I wouldn’t recommend using it in any other company but for that organization it was like a tailor-made glove. It suited perfectly. On the different hand it would probably look and work lousy. And it would have brought another load of mess.
I’m far from blaming applications for problems with bug tracking. I’m even further from redevelopment of a way we manage bugs and feature request. I prefer to start with doing it right in the old-fashioned way, like a grandma taught us.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
