Systematic Debugging

The process of systematic debugging can be summarized in the following flowchart.

Professional software developers spend about half of their time validating and debugging software.¹

So, you should not feel bad about spending most of your time debugging! You can think of "debugging" as a domain-specific term for "problem-solving." Don't view it as a mistake or defect! When viewed as a problem-solving practice, it is imperative that the "scientific method" is the best strategy to approach it. Homework-1 teaches you hypothesis-driven debugging that captures the idea that we can use the scientific method to make debugging systematic rather than ad-hoc (haphazard).

Here are a few other tips:

• Understand the problem and its solution before debugging the code. If finding the solution is part of the task, first solve it on paper (so to speak); once you know you have a correct and working solution, implement it.

• Always confirm your hypothesis before making any changes to the code. And when you do, change one thing at a time.

• If you can't figure it out, sleep on it! Take a break and come back to your code. If you're too tired, you won't be an effective debugger. Trade latency for efficiency!

• Search the internet for the issue (sometimes it is a known bug within the software or a common coding mistake).

• Discuss your bug with your friends (don't share code unless you partner for that activity). Simply explaining the issue to somebody can trigger new ideas as to what the problem might be. (Do you know The Rubber Duck Story?)

• Ask about your bug on the course forum! Somebody with experience may be familiar with a similar problem, the system, and how to find the issue.