Back to Home
So if you are a programmer or developer, you must have heard that “your code is not working, it has bugs!”. And then you got angry and you supposed to make a plan to kill that man who told you that. But calm down, Pal! Before killing and going to jail, you should be doing a lil bit of debugging and kill that buggy issue.
So let’s be formal. The above paragraph has two buzz words:
I would like to enlist 8 general debugging tips below. But believe me, there are more.
Debugging is painful. No one likes to debug as most of the time, it takes a huge portion of your day. Moreover, it does not create any new value.
So, what you do when you find someone else’s bug? Do you spend time blaming him? I believe you don’t because blaming someone is not a solution. The bug you are having right now is your problem. It doesn’t really matter whether the bug is your fault or someone else’s. You have to embrace the fact. So instead of blaming, keep concentrate on fixing the bug. Actually, in most IT farms it is a part of Culture. For example, the company I am currently working at strictly follows this rule.
Let’s assume a situation where a programmer Rahim developed an application but later the testers reported that his application crashed every time when they submitted the person registration form. When Rahim heard about the issue he said that he could submit the form and it worked fine. So tensions became rising among the team.
To ease the situation the project manager set up a meeting with Rahim and the tester who actually had found out that bug. During the meeting, the tester said that when he had not provided any date and afterward submitted the form, the app exploded.
Rahim said, “Oh, I see!”, in a small voice. Rahim admitted that he had provided a birthdate when he submitted the form, that's why he was able to submit the form without any issues. Rahim should handle the case while the birth date is null or empty.
Lessons from this story are:
Whenever you witness a bug, what’s your reaction? It might be “that’s impossible”, or something like “my code can not produce this bug”. I would say, man, it is very important to step back a pace and give a shot to find out what could be causing the bug. However, you can write code for an immediate fix. That's Genius!. But without knowing the root cause, you can’t avoid similar bugs in near future. So dig deep and try to find out the root cause of the problem.
You have to know how to produce the known bug. Because if you are not able to reproduce it, you don’t know the bug is fixed or not.
For example, in a particular situation, we may find a clue and we chase it down. But if we did not note down where we were and when we started the chase, we could lose a lot of time getting back there. So keep pen and paper near to you while chasing the issue.
You must hear the term Binary Search whether you are a programmer or a non-programmer. You can use this idea even in debugging. For example, your registration form has been in production for 1 week with honor. But suddenly it starts crashing. For this type of circumstances, what you would do! The registration form seems a pretty small topic, all it does is it takes data and sends it to the database. So, at first, you need to look at the dataset. You can try looking at the place in the dataset where the form crashes. Try the dataset and feed it through a locally running copy of the app. Then apply the binary search technique to figure out exactly which input values are leading to the crash. It's not the only case to apply Binary Search. You can use the binary search algorithm to isolate the function or code section where the issue is introduced.
For example, you are using a third-party library for the input fields of the registration form. And suddenly one day your form explodes. You get an error message exactly where the error occurs. But this does not give you a clear reason why the error takes place. It typically can’t tell you what you were doing prior to this call chain. So you can put some tracing statements to drill down into the code. It may help you to get to the issue more easily.
Explain it to someone. Right, you heard right! It may sound simple. But you can apply this simple way when you spent a lot of time just finding out the issue by going through the code but was not successful. Sometimes the listener does not need to say a word, the act of explaining step by step might help you suddenly to gain completely new insight into the problem.