Debug with the scientific method and preserve your sanity

Debugging is an art. An art that is honed and crafted over many years and after finding many bugs – you develop a six sense to where problems might originate or how they might be fixed. However, some bugs are just too damn hard to fix quickly – in which case you’ll need the scientific method.

Sometimes the bug your working on is really tough and you just don’t know where to start after you’ve been flailing and sweating for some time – and this is where you need to bring out the big guns … The scientific method.

The scientific method is simply a way of jotting down what steps you’ve taken as you go through and debug your code, which will help you with:

Keeping your sanity
Handing over easily to other developers
Help get your ideas down on paper
Noticing errors in your own debugging practice

The format of the scientific method

Hypothesis – Define what you think might be wrong. Describe what area you’re going to isolate and test. Before you start you might want to gather other colleagues hypothesis and their proposed steps to testing the issue.
Expected result – What you are expecting to happen, this helps to clarify whether the end result is what you thought it was. It’s important to do this before you take steps to test it.
Steps taken – What steps you’ve taken to test that this hypothesis is either correct or incorrect including the inputs, the state of your application prior and any other factors that may affect the issue you’re trying to find.
Actual result – What actually happened as a result, if you didn’t fix your issue you’ll probably want to try to jot down some more hypothesis here too.

You can see by taking these steps someone else can easily ask what you’ve done, what were the results and they can easily follow in your footsteps in getting to the bottom of the issue.

Question: Do you take a systematic or more chaotic approach to debugging?

— Let me know in the comments below!

Author
Recent Posts

Lou Bichard

Hey I'm Lou! I'm a Cloud Software Engineer From London. I created Open Up The Cloud to help people get their start and grow their careers in cloud. I edit the monthly Open Up The Cloud Newsletter which I think you'd really like. You can find me on Twitter or LinkedIn , I'm always happy to chat. When I'm not writing you can usually find me picking up heavy things and putting them down, or riding two wheels (sometimes with an engine, sometimes not).