Annoying bugs fixed quickly are most time-consuming when you have to revisit and check the old bug that you thought you’d moved on from. Knock! Knock! Dear software development folks.
Can you feel it? The fairy Christmas air is around the corner. You already had plans for yourself, but suddenly you look around, unfixed bugs are still dancing here and there. Struggling with these uninvited guests might ruin all your mood for a cozy and joyful Christmas night.
Sadly, you can’t avoid the fact that a digital product soon or late will require a session of debugging in its development process. This is a sure thing because we’re only human, and the problem here is not about good or bad coders, it’s about the process you follow to fix the bugs.
The 5 Steps on Annoying Bugs Fixed Quickly
So, the 5 steps below are not supposed to teach you how to fix a bug, but to show you a reliable process that can help to save your time for more memorable moments, like Christmas Eve. It’s our very own ability to control how we handle issues.
Step 1: Replicate the bug yourself
It’d be better to take some time to replicate the bug yourself and then make careful notes of the replication workflow you’ve found. This is what you need to communicate the details with your team.
It’s crucial that you have your own review of the evidence and come to a conclusion. Just like a detective proving a case or a scientist testing a theory, collecting and storing any necessary document to prove the before and after what was broken and what’s now fixed. Besides, another reason for you to not skip this step: You know your way around the codebase more clearly than your teammates do, so your angle will always be different.
If your work results in the same workflow, you will have more evidence to eliminate suspicious scenarios that zero in on the problem. If not, you have saved your time in the long run by not looking into mechanics that aren’t part of the issue.
Step 2: Make sure you truly understand the problem
The assumption is the root of all mess-ups. If you rashly assume what the problem is without truly finding out about it, you’ll surely regret it later when a linked issue arises.
Once again, we’re only humans, I know it’d be hard but please try to step away from the assumptions and just interpret the issue by looking at the facts. And from here, start to match the pieces into a complete picture.
A great number of different mechanisms are likely to be involved when you reproduce the bug, so it’s essential to pin down exactly the position of the issue in the code. By doing this, you’ll have a firm answer when your team asks “What was wrong? How bad is it?” This also proves your image and ability.
Although there’s a certain way of replicating the bug from a UI perspective. It isn’t supposed to always help you understand the bug. So in short, avoid running on the assumption, even if it happens to be correct.
Step 3: Pair-programming
Sometimes things go harder than you’ve expected. If you find yourself struggling for more than an hour and not making any progress, stop right there! Bring a colleague, better if you guys are working on the same project, and ask him/her to pair-program the way out of it.
Show him the bug and the process you’ve been carrying on. Tell him everything you’ve tried and explained to him your view and opinions about the problem. It’s research-based that we’re more likely to come out with surprising ideas while talking something through and having to explain it to someone else. So by co-working with a fellow. You’ll not only have valuable support from him but also a higher chance to bounce ideas off your head.
At Designveloper, we’re applying this method, and we can assure you it’s totally effective.
Step 4: Alright, let’s start fixing
After clearing what the problem is, you and your pair programmer can now start to work it out.
I think I don’t need to tell you how to recode a bug here, right? As I claimed above, I’m not writing this to teach an outsider how to code. So as a professional, this is the step you can totally handle on your own with your technical knowledge and practical experience. Good luck!
Step 5: Break your fix
The bug was fixed, well done! But stay meticulous, aren’t you thinking of just passing it through like that? Most coders do the test to make sure their solution actually worked. But testing is a vague concept in itself. It can mean anything from simply proving the bug doesn’t exist anymore to retesting the whole product.
To save yourself from the confusion, let’s try to break the applied fix instead of testing it. Why? Because even with a test suite covered by 100% code. You could still miss an important scenario that could present issues. Trying to break it gives you a more explicit goal and helps you and your team bring the work beyond the limits. And from a developer perspective, you are eliminating all possible weaknesses in the product much more effectively.
To Sum Up
If you manage to break it, so sorry, now go back to Step 1 and try again for annoying bugs fixed quickly. If it still remained strong and stable, congrats! Now you may feel completely relaxed and continue your plan for the most wonderful time of the year.
Photo credits: pexels.com
Truc Thuy Minh
Also published on
Share post on
