Before you debug…
It’s worth doing some things first, before you’ve lost three days debugging some stupid problem.
It’s worth doing this before you debug especially when dealing with troublesome, old, boring, stupid bugs. And confusing bugs. And bugs when you’re tired.
Chances are that you won’t though. Neither do I. We, both of us try six million things that we’d like it to be before we look back at the problem and ask… what is the problem?
Here’s what you do: write everything on 1 page.
This is what I include:
Describe the bug
Make sure you have a really good description of the bug – exactly what is the problem. Step-by-step instructions. More detail now is best – you can throw detail away later if you don’t need it.
What don’t you know?
Ask yourself this until the bug is fixed – are you assuming anything? Are you confused? Are you guessing? Are you lost? What information would help you understand the thing – and how do you find it?
WHAT is the problem
The original description is usually vague, bordering on useless – but before you close the issue, you need to make sure that whatever you think the problem is corresponds to what the reporter thought it was…
WHERE is the problem
Complex systems are made up of several components, so make sure you identify that area where the problem really is. If you’re sure then double check to avoid wasting time.
One you have this, you can ask for help, research the bug and do other things in a useful way. What I’ve seen (and done) lots is the developer having an idea of where the problem is but no real description of the bug, so they make a bunch of changes but…. the bug comes back. Because, they never fixed it.
And this happens about a thousand times before the bug is just taken away from them or everyone gives up and begins to like the bug, like some kind of twisted hostage syndrome where the development team is being kept in the office by a terrorist bug. Or something.
—
This is part of a short series of blog posts I’m putting together on debugging methods. Some of this material is taken from my own experience, but much is gathered from other sources. You can follow this at http://www.danfrost.co.uk/blog/browse/ways-of-debugging/.
