Over time, many bug and issue tracking systems decline into a graveyard for bug-reports, a place where problems are buried rather than resolved.

I’m not a developer but even so, any mention of bug-tracking systems elicits unhappy memories. I was once one of the Business ‘stakeholders’ for a system. We performed user-acceptance tests to check that the system was, in reality, what the business wanted. We were told to put all bugs and concerns in a bug-tracking system. For months, we followed the prescribed process diligently. We logged any issue that we or end-users noticed; the developers would review them regularly, prioritize them, and schedule time for fixes – except in reality, they never had time to do this. Developers came and went, the backlog grew, and eventually the project manager announced to us that any bugs in the system more than 2 weeks old would be “closed”. His argument was that if a bug was important we or end users would report it again, and they would then be able to focus their efforts on those. It worked, I guess: it reduced the bug-count, and prevented the visceral panic being experienced by the developers whenever they opened up the bug-tracking system. However, it was certainly damaging to the morale of the customers, and rendered pointless months of drudgery.

I was therefore intrigued when a Redgate developer described to me a rather different approach to issue tracking, for one of the tools. It is an approach based on the idea of never having a backlog. It requires a clearly defined focus for tool development efforts, and knowing when to say “no”, if a bug is outside the current focus or too difficult to fix. It also means constant and clear communication with customers, as well as support and sales staff about what bugs will and won’t be fixed.

The team communicate with customers and accept feedback via email, forums and UserVoice. If a bug reported through these channels is easy enough to fix, they do it there and then. A big advantage to this is that the issue details are still fresh to the customer. If the bug had “rested” in the tracking system for several weeks first, they often struggled to provide reproduction steps.

If a bug is non-critical and too difficult to fix immediately, it is archived until the team can solve the underlying issues that blocked its immediate remediation. However, if no-one else shouts about it in the meantime, then it’s regarded as low priority.

I wonder if one can extract the moral that bugs are symptoms of problems rather than the diagnosis of the problem. Bug reports should not come to dominate the method of work to the extent that every task has its related bug ID. Bug reports must instead inform the judgement of developers in planning their work. They must be part of a dialog with the customers or users of the system. In other words, a bug tracking system must be the servant of the developer, administrator and user rather than their master.