A Simple Debugging Strategy

Debugging is one of the most important and most ignored aspects of programming. The literature on it is sparse; there is barely any training offered on the subject. This is one skill that most programmers have to learn themselves through trial and error.

This is surprising. Debugging is the most intractable task that programmers routinely do. It is one of the biggest contributors to missing deadlines. It can potentially take a big amount of time. We would think that there would be more attention paid on how to effectively debug.

Often debugging happens through a cycle of staring at the screen, changing some code, running the debugger, and repeating until the solution arises from the soft glow of computer screens. With enough stress and pressure the programmer may apply the same three or four “solutions” in series, essentially walking in circles around the problem.

I have found myself in similar situations. So I developed a simple, systematic way to debug to attempt to solve a problem as soon as I can and avoiding falling in repetitive attempts to solve the bug using the same failed fix.

The first step is to understand what is happening. You have a system that you believed worked in a certain way. The bug is evidence that this is not true. So the task at hand is to find accurate information about the system. And to do that we are going to perform a number of experiments.

On a piece of paper, make a simple grid with the heading, “Statement”, “True?”, and “Notes”. Now make a statement about the system that can be falsifiable. For example, we can say, “The class receives bad data.” Write this under the “Statement” column. Now run the debugger and stop at the point where the data is being inserted. You find that the data is correct. So write “False” under the “True?” column. If you find something interesting that you didn’t know, add that under the “Notes” column. If not, then make a new statement about the system. Repeat until you find the error.

That is essentially it. By using this simple method we now have a systematic way to learn more about the system. Now you can track your debugging productivity by seeing how many statements you can finish within 30 minutes or an hour. The list will prevent us from repeating fix attempts.

As a bonus, the developer can update documentation on the system based on the knowledge gained through the debugging process. This is especially important if the solution involves working around the limitations of a framework of a specific technology.

This post was written by:

Hugo
Senior Engineer

For more information on this post, the techniques discussed here, or Zekiah’s system integration and software development services, please e-mail us at contact@zekiah.com