What I learned about issue tracking

After years of leading software projects I’ve learned many good practices about tracking issues. The most surprising and important though, is this:

Each of your issue tickets is costing you a fortune. Keep their number down!

And I don’t mean the engineering cost of the actual fix. No. The mere fact that a ticket exists in your tracking system is a gigantic time sink.

You may think that the ticket is a handy to-do for the work, but how naive is that? Think about it! Someone has had to enter the ticket, filling in all the fields. Some of the fields are hard work: What are the actual steps to reproduce? Where does the behaviour differ from expectations? Whose expectations? Are they right? Then people have to triage the defect and answer all these questions again. Perhaps more: How bad is it? In what context? For this release? For a demo? For the unknown future? How do we carry it over a milestone? If we don’t fix it, what might we have to do?

Then the unresolved ticket will sit in your tracking system for weeks or months, weighing down your project like an ugly, undigestible boat anchor. It will appear in every aggregate report you care to make, making your metrics look terrible. Dozens of people will read the defect and a few engineers will investigate it, perhaps several times. An estimate shall be produced for its fixing, which you won’t like. Then a nominal estimate to fix any possible problems introduced by the fix. And the fix of the fix’s fix. Before long your entire team’s productivity will be swallowed in a vortex of defects, chasing each other and your developers, and you, uncontrollably forever.

Maybe one day someone will fix the code. This will be the only cheap and efficient thing that happens in this story.

Then they’ll try to get the defect closed. Woe is them! There will be a code review. Did you really mean to make the button blue? Yes I deliberately made it blue. So far so good. Then some poor soul will have to revise a spec to say that the button now is to be blue. Testers will test that it is blue. Sometimes, testers will write a regression test to ensure that it stays blue, sort of like politicians who legislate against the last horrible thing that just happened. All of these people will ask the XP customer if they like the blue. Yes, thank you, the blue is nice.

Before you can release the product, and at every incremental milestone, your QA team will laboriously bring out the spec, look at the app and check: This button, red, check. That one, blue… oh no! Now, as a foolish designer or XP customer, you may think you have the right to ask for changes in the software. Say you wanted the UI to have white buttons after all and at some point you asked a developer to make that change. But lurking deep in your development processes are regression tests, from past bugs that have been filed against non-conformance to spec, that lock those specs down at thousands of essentially random points. Innocent changes trip up your regression tests and cause a barrage of false failures as you try to release, draining more time into spec writing and test case adjustment.

There is, of course, a point to having a spec and regression tests and a hawk-eyed QA team. They are there to catch the real bugs, those that would lose data or even kill people in some environments. It is absolutely correct that some defects receive the military treatment. Those that compromise safety and security, vital business, or large running services. But a principle of economy needs to apply. Much like in human interactions, you need to track only serious issues that demand a response, not every deviation from perfection. You need to treat issue tickets as if they are expensive because they are.

You should treat bug tickets like you would treat customer service issues in SalesForce. If you aren’t going to close them within a few days or weeks, either by fixing them or by acknowledging them, then don’t track them. If you need to have your team work on things, like small fixes or changes, just tell them. Treat those informally. Only keep in your bug tracking tool those issues that merit a project or career failure over, and then resolve them.

We use a free tracking tool, and price hasn’t been a factor in the choice. Most of them are quite cheap and charge per user. But what if they actually charged per ticket? As a rough guess, if we had to pay $50 per open ticket per month (an outrageous price) we would save money because it would force us to keep the damn things down. Perhaps at $100 per ticket per month the cost of a valid ticket would match the waste of a pointless one, and even then I’m not sure. Can you save us, Joel?

One thought on “What I learned about issue tracking

  1. Oh how true! I watch people on a customer site triage the same issues over and over again. “this bug was raised on the previous project and deferred. Should we fix it now? Does it still exist – maybe we should repeat the test? Oh, it does! Well, I don’t have time to fix it, defer it for the next project.
    Massive backlogs of deferred issues build up, because no-one is prepared to say “we won’t fix that”

    “won’t fix” is a brave decision, but a necessary one. I actually think you should have tickets for your won’t-fix decisions, so you can block that issue being raised again and the same painful decision being made.

    Reply

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s