Debugging Emergency Kit

The image above is the hand-out of the last talk I gave. Rubber ducks have long been known as one of the most effective debugging devices [1].

Very often, while debugging, you *know* that you are almost there. The problem is that, before you notice, the morning has gone by with you being "almost there". If you don't really get there after a couple of quick and dirty iterations and want to avoid wasting a morning "almost there", it is very useful to make explicit the steps that everyone takes while debugging: enter your notebook and the scientific method (quoting from Andreas Zeller's Why Programs Fail: A Guide to Systematic Debugging)

1. Observe a failure
2. Invent a hypothesis consistent with the observations
3. Use the hypothesis to make predictions
4. Test the hypothesis by experiments and further observations
   • If the experiment satisfies the predictions, refine the hypothesis
   • If the experiment does not satisfy the hypothesis, create an alternate hypothesis
     
5. Repeat steps 3 and 4 until the hypothesis can no longer be refined
   

Keeping a written track of the steps is the key here. The advice is quite obvious, but we often forget about obvious things that work very well [2].

[1] This is not the only surprising ability of rubber ducks: http://en.wikipedia.org/wiki/Rubber_duck#Oceanography
[2] I'm writing this post after a most ineffective "almost there" afternoon