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”.
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!