9 Techniques to Save you from the Bug-Swamp

How many unresolved bugs are there in your system right now?

Yes, yes, smarty-pants: the ones you already know about.

Ten? Fifty? Two hundred? More?!

I find it frighteningly common to see teams let a huge backlog of bugs build up. They set up a trusted system like Jira or Bugzilla and then use it as a dumping bucket for a whole variety of irritations, glitches, missing features, and genuine defects.

Pretty soon the list becomes un-managably large. Nobody dares go in there, because it’s full of bad news. This drains the team’s energy and morale.

Getting on top of, and staying on top of your bug list is hugely important, and I outline my thoughts and experiences on achieving that below.

Draw Some Axes

There’s nothing like getting your bugs out of the tracker system and up onto the wall on a big, colourful, chart to really ram it into people’s faces that something needs to be done.

It’s also a terrific motivator as you start to get on top of the bug list and are rewarded with real visible progress on the wall.

A great simple tool for this is the bug-down ‘finger chart’. Grap your flip-chart or whiteboard pens, and let’s get stuck in.

• Draw an x-axis scale plotting days from today.
• Draw a y-axis scale going up to, say, 1.5 x the total number of bugs your tracker system knows about – open or closed.
• Mark a point for today at the total number of bugs, open or closed.
• Now beneath that, mark a point at the total number of closed bugs.

That gap between the two points is what you need to work on.

The beauty of this simple chart is that it shows you:

• How quickly you’re finding new bugs
• Whether you’re winning the war (is the top line going up steeper than the bottom line?)

Plot these points every day, and rotate the task so that everyone is in touch with the situation.

Turn Bugs into Features To Do

As James Shore says, many items in your bug tracker are probably features in disguise. If an application is in production, it’s hopefully usable in it’s current state, even if it’s doesn’t do everything you wanted it to do in every single scenario.

See how many of your bugs you can re-write like this:

BUG: Users without javascript can’t sign-up. The sign-up form uses AJAX and won’t work for users with javascript disabled.

STORY: As a user with javascript disabled, I want to be able to sign up for the site, so that I can use it like everyone else.

or, perhaps more cheaply:

STORY: As a user with javascript disabled, I expect to see a helpful message telling me that I need to enable javascript to use the site, so that I don’t feel excluded and confused.

Bingo! one less bug to fix. This feature or user story can now be prioritised and planned alongside all the other changes you’d like to make to the software.

Alternatively, take a buggy part of the product and write a story that says something like: As a user in the upload photo page, I expect the site to be bug-free. Now carry all the bugs relating to the photo upload with that story card, prioritise it, and when it comes out of development it should be shiny, gleaming and bug-free.

Bug Monday

Fixing bugs is demoralising. It’s no coincidence that they can usually be found in the grottiest bits of the code, where misunderstandings and mistaken assumptions abound. It’s no fun hanging out there. It’s hard work and requires a lot of energy. Some people find it easier than others.

We found that fixing bugs as a team effort really made a difference for us. The old adage ‘many hands make light work’ really comes into its own here, and by all mucking in together, the team can generate a bug-quashing momentum that no one or two individuals could compete with.

Much better to put the whole team of five onto bugs for a single, horrible day, than to force one poor bastard to do it for the whole week.

Talking of which…

Take, Don’t Give

Assigning bugs to particular people is very close to assigning blame. Anyone and everyone in the team should feel a collective responsibility to defeating and controlling the bug count, and hopefully most members of the team will feel confident enough to dive in to any area of the code to make a fix.

Having said that…

Specialize

Although I’m big on the XP principle of ‘no code ownership’, I’m also a pragmatist. If you wrote the WidgetFragulator last week while I was on holiday, and there’s a bug in the WidgetFragulator, it’s probably going to be quicker for you to fix it. It might, on the other hand, offer a great opportunity for me to get my head around the new code you wrote. Make a quick judgement within the team about what will give the most value, balancing long-term knowledge-sharing within the team against the short-term business benefit of getting the fix done ASAP.

Write a Test

If you’ve got a defect in your code, it’s usually for one of two reasons:

1. The guy who wrote it didn’t know what the software was supposed to do. What he implemented was correct to his understanding of what it was supposed to do, but his understanding was wrong.
2. The guy who wrote it knew what the software was supposed to do, but he made a mistake.

In the first instance, you may well be lucky enough to have an existing unit test that you can modify to specify the correct behaviour. In the second instance you certainly won’t.

By writing a unit test to reproduce the bug, you get to do something mildly creative, you save time tesing out different options for the fix, and you make sure that this particular bug will never go undetected again.

Aim for Zero Defects

David Allen’s excellent GTD methodology promotes a two minute rule: if it will only take two minutes, do it now!

Encouraging your team to take a similar attitude to defects saves everyone a huge amount of time. Rather than wasting effort finding defects, logging them in a tracker, reviewing the lists, prioritising them, re-reading them weeks later to figure out what the hell they mean… just fix it! Now!

This also promotes a culture within the team where everybody cares. They care about the quality of the product, and if they see a typo, they’ll take the time to stop and fix it before moving on.

Keep Shorter Lists

While David Allen’s excellent GTD methodology teaches us that having a trusted system where you can dump everything out of your head will elevate your mind and allow you to concentrate on the tasks at hand, lean thinking teaches us that maintaining long lists of anything is inventory, and inventory is waste.

These two guiding principles apparently contradict.

It’s easy to see how wasteful it is to keep a large system full of bugs: many of the entires may be out of date, for issues that have already been fixed, and each time you open one up you’ll have to waste 30 seconds figuring out if the bug is still relevant. Whatever you do, don’t let your bug-tracker become one great big ‘hmph’ pile for all the things your team can’t make a decision about.

For every bug in there, ask yourselves these quesions:

• Is this really a defect, or can we call it a new feature and prioritise it?
• If it’s a defect, why don’t we fix it this week?
• If we don’t need to fix it this week, when should we fix it by? Does it even matter if we never fix it?

Create Less Bugs

Finally, a really obvious point but one worth ramming home nonetheless. Using quality-focussed software engineering techniques like Test-Driven Deveopment, pair programming and refactoring will help you to quash bugs at source: when the code is written.