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:
  1. Very customizable and configurable
  2. Offers many workflows and views
  3. Lots of plugins
  4. Easy for manager to generate reports (good reporting features)

Things going against JIRA:
  1. Not the most convenient to use for developers
  2. Too much (unnecessary) detail to be filled in for each task at times

Things going for Basecamp:
  1. Easy to use. Clean interface. More like a todo list
  2. Developers like it

Things going against Basecamp:
  1. No easy custom report generation facility
  2. 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.

4 comments:

Yazhini said...

Why didn't you consider bugzilla? It's nice and easy.

Oh, and you could have set the record for having used three bug tracking systems at the same time.

dhruv said...

Haha!! Well, it didn't come up in the discussion at work, so I left it out. Either ways, I'm cool with bugzilla as well...

The most convenient for me (again) is TODO comments in code. As a side effect, people can just scan code to see what is remaining/buggy, etc...

Well, I hope I get a place in the Guiness Book of World Records for this (there actually is a program going on on television about this in India)

Yazhini said...

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.

All this sounds so plausible in theory. :)

dhruv said...

Yeah!! I totally agree. A bug for every tiny thing is completely uncalled for. Hey and 3 cheers for FIXME. Don't forget the TODOs though ;)

What sounds plausible in theory?