How to defeat that pesky bug

What's the longest you've ever spent on a single bug? Hours, days, weeks? Many of us come across bugs in our work (if you don't you're lying). Here are some tips to both juniors and seniors to handle bugs, debugging and how to manage. 

Prioritize - How important is this bug? 

Does this bug need to be addressed right now? Often developers find it hard to debug a problem as they've been asked to drop everything and fix it. Their mindset/thought process was on another task, and now they've been pulled into something else. Which they may not see as being as important, meaning they already have a negative mindset towards the task. 

If it's not important or critical, add it to the backlog and allow developers to pick it up when their plates are less full. If it is important, make sure that the developers get to a point where they can break off, take a quick coffee break and then can be in the right mindset to debug. 

Don't be scared to take a break

Don't be scared to sit back and let your mind wander. As a rule of thumb if you've spent more than 20mins debugging take a 2min break. Going over and over the same code prevents your brain from thinking logically. You begin to memorise the pattern of the code running, so you're prone to overlooking why something is happening.

If it's been more than 20mins,  and you're still banging your head against a wall. Take a break, do something mundane like scroll a news article, walk around the office, or home for 5mins. Usually doing something like this can reset the cognitive side of your brain for solving problems. Go back to the code and try again, with a fresh pair of eyes.

Park It For Later

If you've already done step 1, and realise this isn't a critical bug, run a `git stash` and park it on the bench. Pick up another short task to take your mind off it. Sometimes just a change of task can trigger a solution to your original problem. Studies have shown that the unconscious mind is able to take over and solve problems, whilst your conscious mind focuses on other tasks. This can be read further in this article by Psychology Today

Debugging - Breakpoints

Breakpoints are your friend! Sometimes they're overlooked, and how useful they can be. It doesn't matter what language you're coding in, just place breakpoints throughout your code's pipeline. Personally, I prefer to place breakpoints with larger gaps between them, to begin with, and let the code run its course hitting these checkpoints. 

This allows me to say it gets from 1 > 2 > 3 but then breaks. So I know the issue is between 3 > 4. I can then delete all other breakpoints and place more between 3 > 4. Once I've narrowed it down to a particular area, or a couple of functions, I can then use the built-in debugger tools to step through the code line by line to target code causing the bug.

EUREKA - You've found the bug! Now to solve it

Breaking it down 

Over the years I've seen many both junior and senior devs try and fix a bug by looking at the whole picture. Once you've debugged and found the cause, rather than trying to fix the whole problem all in one go, micromanage the solution. Break it down into much smaller chunks, or "tasks". 

Take the analogy of a burst water pipe. You know the end goal is to replace the water pipe. But before we can do all that first thing is to stop the water flow, then call a plumber to assess, then order & fit the parts. Problem solved. 

However, developers can sometimes get caught up on just knowing they need to replace the pipe they can't see past that. Breaking the problem down into smaller more manageable chunks means not only do you get a more frequent sense of achievement, therefore, boosting personal morale, but it can potentially make the code more robust, independent and structurally sound. 

 

Putting in measures to help prevent bugs 

 - Post bug Report / Retrospective

Once the bug has been identified and fixed, now is the time to identify what caused it in the first place. Firstly this is not a blame game; this is not an opportunity to point fingers, but more of an opportunity to address where things went wrong.

Address where the flaws in the development lifecycle are. Was it lack of understanding/requirements on the developers' side, was there a lack of testing or did QA sign off on something that wasn't right? 

A retrospective or catch up with the team once the bug is fixed, allows the full team to learn from the problem and help put things in place to prevent it in the future.

 - Automating Regression Testing

Integrating automation testing into the release pipeline means that any un-expected breaking changes are found earlier. This not only means that the code doesn't get deployed to clients / live servers, but it also speeds up the QA process. QA testers do not need to spend hours testing if the existing functionality of the site has been compromised and can continue to focus on testing new functionality/features manually. 

Once these new features have been tested manually, the manual test cases can be interpreted into automation tests and added to the regression pack.

- Thorough Testing

QA (Quality Assurance) means just that, quality. What's the point in having a QA Team, if the quality of the tests is anything but, top quality.  Teams should make QA one of their biggest priorities within the development lifecycle, as they are the final line of defence from your code hitting the public eye. 

Another analogy - let's take a medieval castle

Developers look at the requirements from the King or Queen, on what they need to build, to keep the royals safe, what they want and can afford. They gather a solution and implement it to the best of their ability.

The QA /  testing team, test the wall against the requirement set forth by the King/Queen, for example (strength against rocks, paper, scissors?). They're the people that say "yes we've tested all possible forms of attack and all requirements have been met ". This should assure the King or Queen that they are safe and can "welcome an attack" i.e release the code to live server.

Some may say that the Devs and QA Team only do as much as the requirements inform them to, as that's all they have to go on. However, this is the key part; there should be communication between the testers and developers to clarify how the requirements have been interpreted, and the testers should use their experience to make suggestions on areas which may have been overlooked by the royals or developers.

The QA team, should assume that the Royals and Developers are going to make mistakes or misinterpret things, and plan for these by writing thorough tests, and spend time on planning for all eventualities.

Summary

So in summary, the way to defeat a bug is time, patience and a proactive approach to work. As a developer take your time, as a QA team member, plan ahead and learn from experiences in your career. These are the key aspects of improving your quality of code, and preventing detrimental bugs in the future.

I hope this has helped you or at least gave you some food for thought. As always if you wish to discuss drop a message in the comments section, or tweet me @GWeaths