Steps of debugging

If you’re like every other developer out there, you spend a fair amount of your time debugging code rather than writing code. However, it’s amazing that despite so much of our time being spent in debugging, a lot of us never really do it in a systematic way. Each of us debug stuff on our own way as bugs present themselves – and a lot of the time, we end up wasting too much time on what could otherwise be a quick fix.

Following is a list of techniques that John Sonmenz recommends in his book The Complete Software Developer’s Career Guide which I’ve found to be useful in debugging time and again. And I believe everyone should follow this process. Pro tip: Don’t open your debugger right away.

  1. Reproduce the bug first – there is no “bug fixing” without the bug.
  2. Think about what might be causing this – don’t just start with the code yet. Form a hypothesis. Make assumptions.
  3. Write unit tests to verify your assumption. This not only helps you test your assumption – but also allows you to catch if this bug would occur again in future.
  4. If unit tests are not helping, re-visit your assumption. It is often possible that our first assumption is not where the issue is. Think again.
  5. If you are out of assumptions, then finally open your debugger. If you know where to look, debugger will be helpful at this stage. But otherwise – be aware of losing track of time in debugger – you may end up spending hours without moving ahead.
  6. If nothing helps, then “divide-and-conquer”. Divide the problem domain by half until you’ve reached the source of the bug. This always helps.

You can read more about these steps in John’s blog post too.