Just something whacky to get you thinking. At least it got me pulling apart my hair, and now, I'm half bald.

Sunday, March 20, 2011

Issue list in code

A few weeks ago, there was a debate/argument/discussion about what issue tracking tool should be used for our project. The 2 main contenders were JIRA and Basecamp. I'll try to capture the essence of the discussion.

Things going for JIRA:

Very customizable and configurable

Offers many workflows and views

Lots of plugins

Easy for manager to generate reports (good reporting features)

Things going against JIRA:

Not the most convenient to use for developers

Too much (unnecessary) detail to be filled in for each task at times

Things going for Basecamp:

Easy to use. Clean interface. More like a todo list

Developers like it

Things going against Basecamp:

No easy custom report generation facility

Not reporting/manager friendly

We've decided to try both out for a few months and see which one "works out" for us. We were using JIRA before, but the enthusiasm seems to have died out after a few months and the issue tracker is not in sync. with the actual issues/reports/bugs/features being developed.

I have an entirely different point of view though. For me what has worked best is comments in code that say something like:

// TODO: Such and such is broken. It needs to be fixed in so and so way.

The reason is that it's too much tedium for me to update things in 2 places (code and issue tracker) when I fix an issue. If I forget, then it's even harder to related the issue to the actual change made. This method offers a way of alleviating that problem.

I'm also okay with having comments that are verbose just so that they can explain in sufficient detail the reason (or purpose) of the code below.

However, this has been mostly for projects where I have been the sole developer. I don't know how well it would scale for projects with 2-3 developers, 5-6 developers and > 6 developers.

I would guess that it's fine for projects with up to 6 developers, but beyond that it would get cumbersome. Also, this way of tracking issues lacks a good reporting method which allows you to track changes across versions. Of course, if you want to adopt this as a workflow, I'm sure some tooling around this general idea can be developed which works by generating diffs between revisions to track which bugs this revision (or set of revisions) fixes.

You know I feel we were completely off when we were creating a bug for every tiny change. I don't mind using bugzilla here because it tracks only significant issues and the minor things go in code as FIXME.