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!