Withhold Judgement When Debugging

When you are debugging your code, refrain from forming theories about the cause of defects for as long as possible. You are initially on a search for truth. Your first job is to gather empirical facts and determine where things are going wrong, not why.

Every process or interaction in your application follows a more-or-less linear path from start to completion. For instance, a form submitted in a single page app is kicked off with an onClick or onSubmit handler, sends an HTTP request to the server, which processes that request and sends a response to the client, which processes that response and renders the result.

If something goes wrong in that sequence you want to pinpoint where it went wrong before you start forming theories about why. Find some points in the path of execution where you can evaluate correctness. A good start in the example above would be to pop open your debugger and inspect the outgoing HTTP request and its response. You can infer a lot about the location of the defect based on whether those conform to the values you expect. If the outgoing request looks wrong, the issue is probably on the front end prior to the request being sent. If the request looks right and the response looks wrong, the issue is probably on the back end. If the request and response both look right, then the issue is probably on the front end, after the response is received. Then continue narrowing down until you can't go any further. Only then do you form a hypothesis about the cause.

This is what I mean when I say you are initially on a search for truth. Your first job is to find the point where the execution of your code diverges from the expected path. If you are ruthless about this you can often locate the problem to within just a few lines of code, at which point the solution is often obvious. Even if the solution isn't obvious, it is much easier to form a credible, testable hypothesis when you're looking at a small surface area of code rather than the entirety of your execution path.

Next Up:
Keep a Bug Journal. Really.

Previously:
Simpler Behaviors are Easier to Specify Accurately


Want to impress your boss?

Useful articles delivered to your inbox. Learn to to think about software development like a professional.

Icon