The Fundamental Philosophy of Debugging in 2021
The Fundamental Philosophy of Debugging in 2021
Understanding debugging
In all of software engineering debugging is undoubtedly one of the most challenging tasks. To be more adept at it we very often opt for specific tactics but they usually don’t help much. A great debugger needs to have philosophy which in other words is a whole new level of problem-solving skill derived from functional principles and orientations.
Debugging is actually a domain specific alternative term for problem-solving. Bugs can also be defined as word problems. In software almost all bugs can effectively be described as word problems and these are extremely difficult to learn. It seems that there is no proper pedagogy around them even in top institutions of technology. So, a trial and error method is applied to find out good debuggers. This problem differentiates between programming experts and novices who try to learn expert techniques. Unfortunately, even experts differ widely in their skills in debugging. However a most effective debugger is likely to possess an extensive experience together with fine-tuned and cultivated problem-solving skills. Experts apply generalized strategies towards solving problems and refuse to treat each individual bug as a new specific case.
The proper approach
It’s so strange that some amongst us can easily walk their way through all the unknowns. They usually do not get frustrated and possess a sixth sense to detect and analyze the exact problem with remarkable efficiency. You may call it as the person’s experience, intelligence or technical knowledge but that’s not what the story is all about. There’s something profound happening here. You’ll see that the best debuggers have a common characteristic of embracing any problem whatsoever, wholeheartedly. Tactics are absolutely useless without this foundational aspect. Well-founded in philosophy this is a prerequisite to productive debugging.
Ways to accomplish debugging
A. You have to comprehend and recognize the fact that you do not have the answer when you commence debugging although it’s very tempting to think that you already have the solution. You may get lucky with your guesses sometimes but that would not happen very often. However even this small probability tricks people into thinking that good debugging can be achieved through guesswork. This serves no purpose except wasting days guessing the solution and applying different fixes without any result and finally complicating the code. On the contrary, on fixing a bug, some parts of the system get removed. Consequently it becomes simpler and better by design. The fact is that, code gets deleted and the system becomes simplified in search of a good fix for a bug. So, guessing and imagining reasons for the problem are waste of time. It’s only worthwhile to remember how a working system functions like and to find out where you should look at to collect more data.
B. To accomplish debugging you need to gather data until the cause of the problem is understood. You can gather data most of the time by looking at something. Look at the web server’s logs if it’s not serving pages. Another way is by reproducing the problem so that when it is occurring you can try to find out what the server is up to. Once the bug is clarified you need to look at different parts of the system. Your knowledge about the system comes to your rescue here. These parts are usually the core dumps, logs, error messages, monitoring or any other output. Otherwise before the system can be fully debugged you have to set-in-motion or introduce a new version of the system to get information. In spite of this process appearing to be a lot of work for fixing a bug, actually, releasing a new version is a surefire way to get the required information faster. It’s futile to hunt around the system to find out, what’s going on, without any information handy. Frequent and fast releases allow you to garner new debugging information swiftly.
C. Accomplishment of debugging happens by comparison of data between your knowledge of how data from a working system should appear to be with the actual data that you are in possession of. A bug can be less fixed or more fixed depending on the depth of solution you want to delve into as well as the time at your disposal. Most of the time, you’ll be aware of, when a decent cause of the problem is identified and so claim the bug to be fixed. In other words, the simplest step is to fix the cause once it is identified.
That brings us to the four primary steps to debugging.
1. Acquaintance with what a working system does.
2. Realization that the cause of the problem is unknown to you.
3. Looking at data until the causes of the problem are found out.
4. Mending and patching the cause and not the symptoms.
