The 6-Step Technique To Reliably Fix Any Bug
I defy you to show me a digital product that hasn’t required debugging techniques in it’s development process.
As developers, we’ll always be faced with issues and bugs within the systems we build, after all, we’re only human.
However, we can control how we handle them.
I’ve been working for years in web and product development, and I’ll admit I’ve found out the hard way that taking shortcuts to squash a bug doesn’t work. In my experience, those bugs will continue to haunt you and find new ways to cause problems.
I’ve now developed a reliable process that I use to fix all bugs that come my way.
The more disciplined I am with this 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 totally worth the effort.
I hope these steps can be of help to you too.
Step 1 – Replicate the bug yourself
Take the time to replicate the bug yourself, even if someone else has already done this for you. Then make a note of the replication workflow you’ve found, 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’s now fixed.
There’s another reason you don’t want to skip this step: You know your way around the codebase better than they do, 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 causing the issue. If not, then you have saved yourself time in the long run by not looking 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 looking at just the facts.
From here, 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.
This also strengthens your team’s confidence in your ability. It also gives you the peace of mind that you’ve tweaked the right piece of code that causes the issue.
While you have a solid way of replicating the bug from a UI perspective, this may not necessarily mean you understand the bug.
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 problem!
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 it 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. It can also mean 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, 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?