The Ways of Debugging Part 1: Finding the Possible Root Cause

Background

Debugging can be easy for someone, and very hard for the other. After many years of debugging experience, I find that debugging usually consist of 3 big steps, that is:

1. Finding the possible root cause,
2. Prove the possible root cause to find the real root cause, and
3. Fix the real root cause

Additionally, debugging hardware has many similarity with debugging software, in which also has the 3 big steps above.

Finding the Root Cause

Finding the root cause is the very first step in debugging. In my opinion, it is also the most determining step. The total time required for debugging usually be heavily determined by finding the root cause. It is harder to find the root cause rather than fix the system.

In order to find the root cause, the very first requirement is to understand the system you are debugging. I have once need to debug a system in which I do not understand at all, and it takes the time for me to understand the behavior of system first. Only after that then I can finally continue to find the possible root cause.

Moreover, don't be surprised. Sometimes user will actually submit a bug, without steps to reproduce (especially in entrepreneur system, where the user usually know little of software engineering), complaining about a behavior that is already behave as designed. Without any documentation (that's right, no documentation at all!) about how the system behave, I need to find a person who know the system's behavior, to determine whether it is a bug or not. This is, why at most of the time, usually the tester can find the possible root cause easily, because they know well how the system behave.

Understanding the system first can also be very critical for finding some technical flaws. There flaws are such as race conditions, replication issues, different regional setting, different input format, hacks or security flaws, etc. Right, bad system design can be a root cause for bugs, with additional factor like not understanding the system, it will give you a headache.

Another requirement for finding the root cause is having decent technical knowledge about the platform or programming platform the system use. Some platform used by the system such as the database and application, usually has different behavior between each other. Say, for example, java mark the class and method as virtual by default, and in C# you need to specify with the "virtual" keyword.

Conclusion

Understanding the system and having knowledge about the platform will give you significant boost in time needed to find the possible root cause. I have experienced that I have once finding a possible root cause for a bug in system for only several minutes. It is, of course are made possible by the having knowledge of the system.

Much or less, documentation about how the system behave will help newcomers or debugger to find the possible root cause. Not only it will help to find the possible root cause, the handler can instantly know whether the bug raised by user is actually the system's design or not, or they need to configure something in for the user in order to able to do the required action.