Keep Calm and Start Debugging
Updated: Jul 20, 2022
Wednesday, August 16, 2017
" If Debugging is the process of removing the bug, then programming must be the process of putting them in" - Edsger Dijkstra While talking about being a pragmatic programmer in "Let's just not Code, Let's Develop Something", we missed out on one of the most important aspects that a pragmatic programmer must expertise in. And also my favourite topic, which I am currently working on. The "bug" is described as the "Object of an error". No System is 100% bug free, every system has got some or the other bug, and debugging takes the major part of the day. A proper mindset is required to figure out what went wrong and what possibly might have caused a bug. This requires full concentration and a mind that is free from all other pressures. Last but not the least get yourself comfortable and start with the following :
Don't panic : It is very important to take a step back, and actually think about what could be causing the symptoms that you believe indicate a bug. Do not panic about any of the deadlines and don't waste a single second on the thought that begins "but that can't happen" because quite clearly it can, and it has. Always try to discover the root cause of a problem, not just this particular appearance of it.
When you start just make sure that code that you are looking into is compiled without any warnings or it doesn't have any conflicts around. We need to concentrate on the harder problems at hand.
When trying to solve any problem, you need to gather all the relevant data. You first need to be accurate in your observations.
Remember to interview the user who reported the bug in order to gather more data than you were initially given.
Test both boundary conditions and realistic end-user usage patterns properly.
As far as I understand debugging skills are measured on 3 bases :
Complexity : How complex it is to debug an issue ? Does it require the knowledge and skill that you are still working on , or you are an expert in a technology which the bug relates to. It is important to understand what knowledge is required to debug the issue. And an individual's knowledge is one of the factors that determines it's complexity.
Experience : For some people this comes first , because someone with 5-6 years of experience of developing projects on a specific framework might be able to figure out the root cause based upon his/her experience in a couple of minutes compared to the time that a developer who has just joined or is having an experience of not more than 2 years will take.
Efforts : In my opinion, this is the biggest factor that determines how good you are / you will be in developing your debugging skills from time to time. The more you sharpen your tool the more you get the insight of what power it holds to conquer the world.This is my understanding of how the skill sets vary from person to person. You can add to the points above or leave a comment in the comment section below of what you feel about the factors.
This brings us to a part where we will now look into few debugging strategies that will help us come up with the reason as soon as possible.
Visualize your Data : One of the easiest way of to discern what a program is doing or what it is supposed to do is to get a good look on the data that it is operating on. What values are being passed to it. One of the best examples as per my experience : We were supposed to remove few taxonomy terms assigned to a node. There were 3 vocabularies namely : a) Music b) Tv Series c) Movies. Out of which the node was assigned with terms from only Tv Series and Movies , but no terms were assigned from the vocabulary "Music". When the form that contained the values of the terms were to be removed submitted. It was throwing an SQL error that said : Integrity constraint violation: 1048 Column 'field_music_taxonomy_terms_target_id' cannot be null But the code contained the default value which was set to blank like field_music_taxonomy_term = ' '. We looked into the database to figure out why this was being thrown and figured that the table column accpets value that is NOT NULL and accepts and empty array. field_music_taxonomy_term = array(). This pretty much explains the importance of the above mentioned strategy.
Tracing : Debuggers generally focus on the state of the program now. But what is also important is to see and trace the state of program over time.Seeing a stack trace can only tell you how you got here directly. It can't tell you what you were doing prior to this call chain, especially in event-based systems. Tracing statements are those little diagnostic messages you print to the screen or to a file that say things such as "got here" and "value of x = 2." It's a primitive technique compared with IDE-style debuggers, but it is peculiarly effective at diagnosing several classes of errors that debuggers can't.
Rubber Ducking : The most interesting strategy that works a number of times when trying to debug an issue. The idea is to explain the issue to someone who doesn't know about it. While doing this you will explain the issue in terms of steps and explaining the steps might help you figure out what is missing. It sounds simple, but in explaining the problem to another person you must explicitly state things that you may take for granted when going through the code yourself. By having to verbalize some of these assumptions, you may suddenly gain new insight into the problem.
Follow these simple steps and slowly you will observe that you are improving. Keep a record/track of your progress. Even if you fail it is important to understand the reason of the failure and the achievement is when you face the same situation and you know how to tackle it this time.