Bug tracking

All software has bugs; the trick is to find them and remove them as quickly as possible while balancing against the other development you have to do. This is where bug trackers come in: they allow developers to project manage these activities while allowing users and other members of their organization to submit issues while not interrupting the development workflow.

Even though every software project needs a decent bug tracker, finding one isn’t easy. Everything seems to have a downside:

  • Bugzilla, while very powerful, has a near-psychotic user interface – or at least, I nearly went psychotic trying to use it. I’m the technical lead of an open source project with a computer science degree and twenty-five years of programming under my belt; an ordinary user stands no chance of reporting issues in a meaningful way.
  • Lighthouse is really simple and integrates well with email and things like Basecamp. Unfortunately, it’s so simple that certain features – like a drop-down menu that allows users or developers to suggest the priority (or complexity) of an issue – have been deliberately left out of the mix with no hope of inclusion. That means there’s no way of saying that a massive privacy flaw is more important than a minor rendering error, except by integrating with another product.

In the end, Trac seems to be the best solution. Integrations with the Eclipse development environment and Subversion source code repository (through plugins) are a definite advantage, and although the web interface leaves a lot to be desired, it’s nothing like Bugzilla.

The perfect bug tracker needs to encompass these two values:

  • Project developers must find it a significant help, not a hindrance.
  • Users (and project managers) must be able to easily submit useful bug reports, issues and feature requests, and follow progress on them.

Useful bug reports are ones that aren’t duplicated and effectively describe the problem so that the guesswork required on the part of the programmer is minimized. In some ways, both bullet points would be satisfied by a bug submission wizard that falls back to an integrated form once users have become used to the process. At any rate, it requires some empathy on the part of the user interface designer, and more of an emotional approach to the interface design.

In the most perfect world, this would also be fulfilled:

  • In an open source project, external developers must find it easy to contribute code through the same interface.

I’d be interested to hear recommendations for any other products – or to hear any bug tracker horror stories from developers and users alike.

Image Lucanus cervus taken by CCCvrcak and distributed under a CC attribution license.

4 responses to “Bug tracking”

  1. I've nosed around Redmine a little, but I haven't played with a demo or anything (the official one appears to be permanently offline). I don't have a Rails environment that I can test with, but I assume that the Redmine site itself is running the software – with that in mind it definitely looks like an improvement, if not the user-friendly panacea I'm after.

  2. Hmm, what versions of Bugzilla have you used? A lot of people hack up their Bugzilla locally so that it doesn't resemble upstream at all, and also, we've been doing a lot of UI work in recent versions. (Unfortunately UI work had to wait for a lot of backend work for several releases, but now that that's all done we're completely interested in improving the UI.) Anyhow, you might want to also try out the latest CVS code:



Leave a Reply

Your email address will not be published. Required fields are marked *