malvasia bianca

Once again, I find myself at a job that uses bug-tracking software (JIRA this time, as in my previous job; the job before that used Bugzilla); once again, I’m finding that the bug-tracking software gets on my nerves. And, it turns out, gets on my nerves specifically because of ways in which that software seems actively anti-agile.

First: bug trackers are information absorbers. Because, while bug trackers sound like they could be useful as information radiators, encouraging people to put their thoughts and knowledge on a topic in some place publicly accessible, in practice they seem to me to have the opposite effect. In most of my recent jobs, I’ve been part of a team that’s working in close proximity with ample opportunity to discuss topics face-to-face; but we’re too introverted to do that. That’s okay, we have mailing lists and chat rooms where we could talk about problems we’ve noticed and brainstorm solutions; but we don’t do that either! Instead, we file bugs, bugs that almost nobody else notices.

Of course, it would be possible for the bug tracker to send updates to everybody, turning them into mailing lists with some useful auxiliary tools. But they don’t do that by default, and defaults matter. And, in fact, JIRA doesn’t (or at least didn’t the last time I checked) provide a mechanism where people can subscribe to all bugs by themselves, doing that requires administrative intervention. (Of course, JIRA’s information absorption possibilities are exceptional: I have no idea what JIRA’s authors were thinking when they designed its search box.)

Second: bug trackers encourage individual ownership. I’m sure it’s possible to set up a bug tracker without adding multiple categories, but I’ve never seen that done in practice: instead, the administrator picks categories corresponding to components of the system, and picks owners for those components. So, when somebody files a bug, that person picks a category that seems relevant, and the bug gets assigned to that category’s owner. (And, because of the information absorption properties mentioned above, quite possibly nobody other than the person who filed the bug and the component owner will ever learn about it!)

Third: bug trackers work against prioritization. Which is ironic, given how bug trackers love priority-related fields: priority, severity, target release, etc. But, in the agile world, prioritization means that the business side picks a very small number of tasks that are most important to work on right now, the development team works actively on those tasks, and the development team sets all other stories aside. And I’ve never seen prioritization systems in bug trackers that map to this workflow, or indeed that don’t actively work against this workflow.

Fourth: bug trackers work against clean code. Because bug trackers make it feel like you’re doing something useful if you see a problem with code (if you add a problem to code!) and report it. But you haven’t actually helped the code base by doing that; on the contrary, you’re giving yourself permission to leave the code base a little worse than you found it instead of a little better than you found it.

I won’t say that it’s impossible to get bug trackers to work in an agile fashion. And, in fact, the above points at what you should do if you want to pursue that course of action: have everybody receive updates for all bugs, either ignore the owner field or have the owner field always default to somebody on the business side, have as few priorities as possible (probably just two, namely “right now” and “later”), and keep an eagle eye out for clean code. But: defaults matter, the very existence of knobs and bells and whistles matter, and they all point in a rather different direction.

Despite all of that, there’s something that I like about bug trackers. It’s not something from agile, it’s something from GTD, and it’s something that I currently see as a point of tension between those philosophies. Namely:

Fifth: bug trackers encourage inventory. Bugs pile up, with every bug tracker I’ve worked with containing thousands of unresolved bugs in a shockingly short amount of time. And that inventory has all the problems that agile and lean teach us to expect.

Except: GTD teaches us that, if something comes across your mind, write it down. That certainly applies to problems in your code; and, if you’re going to write problems down, you should write them down somewhere that’s publicly accessible and where your notes won’t disappear. So private notes, mailing lists, and chat rooms actually aren’t a great place for this sort of thing: you instead want an area that has at least some of the attributes of bug trackers.

So how do we do this in a way that acknowledges the problems of inventory? GTD has one suggestion, namely the weekly review. So somebody needs to look at all open bugs every week.

Which is completely unworkable with the volumes of open bugs that I’ve seen on projects in the past. This is useful backpressure: if you have too many bugs to review them on a weekly basis, then stop writing so many bugs! Keep your code clean instead. Or, for “bugs” that are nice ideas but just end up not being pressing for week after week after week: just close them once your brain has come to terms with the fact that they’re not something that you think will ever be a good idea unless the context changes significantly. (But don’t close them until your brain has come to terms with that: GTD is all about listening to what your brain has come to terms with.)

Despite that last backtracing, I’m still quite dubious about bug trackers: I’d much rather focus on broad conversations, physical prioritization tools, and clean communal code, and see where that leads us. But I hope it leads us in a direction that isn’t averse to GTD’s insistence on trusted repositories outside of your head.