Why We Made Our Own Bug Tracker

Part of starting the development of Sonnet Models was choosing a bug tracker. Knowing that reinventing the wheel was a bad thing I decided that we should do it anyway.

Why would I do this? Knowing full-well of the existence and having used numerous bug trackers I decided that they all suffered from one common flaw: bloat.

Bloated with Fluff-Fields

If entering a bug requires more than 20 seconds of entering other fluff (such as priority, origin, area, etc etc) then small bugs will simply not get entered most of the time because it takes too long. It’s hard to admit that people are lazy but I’ve seen it happen too many times, “I’ll just add this bug onto this other issue to avoid trying to remember what to put in field X”.

I also believe that people tend to rush filling in such fluff-fields and the result is that much of the data is junk.

What do we Track?

In our bug tracker we have nine fields per bug.

Three of these are automatically generated and cannot be modified (created date, creator, modified date).

The other six are: type (bug, feature or admin task), summary, details, timebox, status (created, ready for testing, pending release, closed) and assignee. That’s it. I’m even considering binning the type field as we rarely use it (fortunately it defaults to bug so there isn’t an admin overhead here).

We allow commenting – but there is only one field – comment.

Drawback – No Sexy Reporting

Sure, I can’t query the bugs database to see the most common origin of bugs, but, as a start-up we have a very good feel for this and knowing the exact numbers wouldn’t justify the cost in time of collecting this data.

I also feel that the lack of sexy reporting is an advantage – I don’t spend half my afternoon trawling through meaningless reports looking for imaginary trends!

Question for Large Companies

Do you actually get any use from all the random data you collect? Or is it slowing you down? Are bugs slipping the net because people don’t want to have the burden of reporting bugs? (Or the e-mail deluge that normally follows from reporting a bug).

Avoiding the fluff is a hard task and sometimes we should learn to just say “no, we can’t add a field onto our bug reports saying what coffee the reporter was drinking at the time”.

Agile Zen

I’d like to finish this post by mentioning a new tracker: Agile Zen. This is an immensely light weight tracker and if it had commenting… we’d switch over as quickly as possible!


One Response to Why We Made Our Own Bug Tracker

  1. Andrew Flegg says:

    This is one of the reasons I started taskt.com (but never really finished it). In particular so that there could be community voting on issues and bugs (a feature Bugzilla now has) to set the priority.

    But your first point: quick to enter is absolutely 100% spot on.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: