The 6-Step Technique To Reliably Fix Any Bug

I defy you to show me a digital product that hasn’t required debugging techniques to fix a bug during its development.

Developers are only human so we’ll always be faced with issues and bugs in the systems we build, but we can control how we handle them.

From my years of working in web and product development, I’ve found out the hard way that taking shortcuts to squash a bug doesn’t work. In my experience, those bugs continue to haunt you and find new ways to cause problems.

I’ve now developed a reliable debugging technique that I use to fix all bugs that come my way.

I find that the more disciplined I am with this debugging process, the less I’ve had to revisit old bugs that I thought we’d moved on from. It does sometimes feel time-consuming, but the output has been more reliable over time and is totally worth the effort.

I hope these steps can be of help to you too.

Fix Any Bug Step 1 – Replicate the bug yourself

Take time to replicate the bug yourself, even if someone else has already done this for you. Be sure to make a note of the replication workflow you’ve found, as you’ll need this later when you have to communicate the details with your team.

Just like a scientist testing a theory or a detective proving a case, it’s critical for you to review the evidence and come to your own conclusion. This is your key to prove the before and after: what was broken and what bug now fixed.

There’s another reason you don’t want to skip this step: You know your way around the codebase better than someone else does, so your angle will always be different.

If your work results in the same workflow, great! You now have even more evidence zeroing in on the scenario that causes the issue. If not, then you have saved yourself time in the long run because you haven’t looked into mechanics that aren’t part of the problem.

Step 2 – Make sure you truly understand the problem

Assumption is the root of all f&#*-ups.

If you assume what the problem is, this may bite you in the bum later when a linked issue arises.

So try this instead: When you get information on a new bug, step away from the assumptions and try to interpret the issue by looking at just the facts.
From here, you can start to piece the issue together.

A whole range of different mechanics are likely to be involved when you’re re-creating the bug, so it’s important to pin down exactly where in the code the issue is. By pinpointing where in the code the bug was caused, you’ll have a solid answer when your team says to you “Great, it’s fixed! But what was wrong?”.

And not just for your sake.

It also strengthens your team’s confidence in your ability. And it gives you peace of mind that you’ve tweaked the right piece of code that causes the issue.

This debugging technique means you have a solid way of replicating the bug from a UI perspective. However, it doesn’t necessarily mean you understand it.

Avoid running on assumption, even if it happens to be correct.

Step 3 – Fix the bug

You know what the problem is and you can now reliably prove a fix to others.

So now…go fix the bug!

I can’t really help you with this, sorry. I know, you read the title and you assumed I could. I couldn’t be more sorry and I’m British, so you know I mean it. I’ll just be here waiting patiently with my tea!

Step 4 – Prove the fix

You’ve fixed it, well done! Now you can prove you’ve fixed a bug using the replication workflow you made a note of in Step 2. Perfect, everyone’s happy.

Though we’re not quite out of the woods yet…

Step 5 – Don’t test your fix. Try to break it.

Testing is a vague concept in itself.

Testing a fix in a digital product can mean anything from simply proving the bug doesn’t exist anymore in the original scenario to retesting the whole product.

Save yourself the confusion. Don’t test the applied fix. Instead, go in and try to break it.

Here’s why: Even if you have a test suite with 100% code coverage you could still miss a vital scenario that could present issues. Trying to break it gives you a goal and helps you and your team push your work to its limits.
In the short term, it may not be very satisfying to discover new bugs or different scenarios that recreate a bug. In the long term however, it gives you and your team a sense of trust in your own work.

From a developer perspective, these debugging techniques mean you are weeding out weaknesses in the product much more effectively.

Step 6 – Closing the loop

Did you manage to break it? Oh dear. Go back to Step 1 and try again.

If you couldn’t break it, congrats! Don’t you feel so much more relaxed knowing that you know exactly what you’ve fixed?

Our product management blog has even more articles on a range of PM topics.