The science of debugging

The perception is that software development is developers creating features by writing code. The reality is different. As developers, we actually spend most of our time finding and fixing bugs… Feature development is just what we do in those little breaks between debugging.
For something that occupies most of our time, you’d think most be very good at it.. But often not the case. The sad thing is that we often don’t use humanities best tool for acquiring knowledge: The scientific method. When people say science, thoughts often go to beakers, lab coats and weird hair. Where actually, science is just a series of steps used to acquire knowledge. Each step is critical in the process.
The steps are as follows (shortened for relevance):
  1. Ask a question –  Obviously, we can’t find an answer if we don’t have a question
  2. Do background research – someone may have already answered our question or had a similar question.
  3. Construct a hypothesis – A hypothesis is a potential answer. The hypothesis must be unpacked into a series of predictions.
  4. Test the predictions with an experiment – Critically, we test to prove them WRONG. The sooner it’s proved wrong, the sooner we stop wasting time on a flawed hypothesis.
  5. Analyse your data and draw a conclusion – Spend time on the results. Nothing wastes more time than misunderstood results.
  6. Communicate your results – Communicating our results allows others to validate the methodology and test the results
  7. ..aaaaannnd repeat
Back to debugging…
When we have a bug, we have a question: “what is causing this sh*t to break!”. The scientific method is the most effective way to this knowledge if applied as a simple heuristic. First step is background research.. Google the error code, method and other relevant information. This is done right up front. We shouldn’t waste time on a problem that someone has already solved.
Based on our findings (or lack of), we construct a hypothesis – a falsifiable hypothesis which has testable predictions. If our hypothesis is un-falsifiable, it is too abstract and should be decomposed into other hypothesis. Importantly, all assumptions are just camouflaged hypothesis. If our hypothesis is both unfalsifiable and can’t be decomposed, it’s an answer that isn’t worth wasting further energy on as there’s no knowledge to be gained. For example: as nice as it feels to vent about it being Windows fault, that’s not a particularly useful hypothesis.
Next, we do an experiment i.e. prod the application in a way that tests the hypothesis and resulting predictions. Analyse our results of the test.. Don’t argue with the results but let the results lead us. If it didn’t behave as expected, we’ve just learned something valuable about our assumptions.
Lastly communicate our results. Most aha moments come from a simple chat to a fellow developer who challenges our biases.
It’s science bitches!