Monday, 29 September 2008

Four ways to find invisible bugs

[caption id="" align="alignleft" width="300" caption="Photo by Chainus"]A visible bug...[/caption]

"I just can't find what's wrong with my code..."

Sometimes you just can't see why your code isn't working.  It's clearly broken , but you have no idea why.  Frustrating, isn't it? Happily, there are good tactics you can employ when this happens to find the problem and fix it.

Get a second pair of eyes
Sometimes having someone else take a look at your code is a great way to spot what you've missed.  Your brain is very good at using assumed prior knowledge to make intuitive leaps, but while this is a great evolutionary trait it can backfire when you know a lot about your code, because it's very easy to assume that a chunk of code behaves in a certain way or is written correctly, when in fact you've used the wrong kind of "/" or your variable's an integer and not a float etc.  The person owning the second pair of eyes won't have any of this prior knowledge, because they're not familiar with your code.  This means that they should actually be better at spotting the error/s that you're missing.  Note also that each person tends to read code in a slightly different way, so they may spot something for which you have a bit of a blind spot.

Explain the problem to someone else
Another similar tactic is to explain your problem to someone else.  Having being deeply immersed in your project, you won't have been thinking about the simple overview of how your code works and what the project is trying to achieve (you're 'too close' to it, in some sense).  Taking the time to explain the problem forces you to adopt a different mindset, which might just be one that helps you spot what's going wrong.  Actually, the 'someone' doesn't have to necessarily be able to respond or even be a person, if you don't mind apparently talking to yourself (or an inanimate object).  The effect can be the same.

Test everything again
You know you're missing something, because your code is still broken.  So it might be worth re-running your tests.  It's tempting to assume that this is pointless, because you've already run all the tests, but just stop for a moment.  Are you absolutely sure that you've done this flawlessly?  Didn't think so.  You know

A good approach here can be to try slightly different tests, maybe with different test data or different input parameters.  You never know when another set of inputs might give you more informative output.  Your goal here is to see if you've missed something the first time around.

Come back later
Sometimes the best thing you can do is stop.  Not only will this give your poor brain a bit of a rest, but it's pretty well established that problem-solving tasks can benefit from the solver being able to subconsciously mull the problem over (while doing something else).  So grab a coffee, go to the gym, go home for the night/weekend.  You'll be pleasantly surprised just how often the solution seems to pop into your head.  This can take a bit of self-discipline, if you just want to get the d*mned thing working.  But sometimes you just have to accept that you won't manage it today, but it'll be a lot easier tomorrow.

Remember to not despair if a bug's being particularly tricky.  You know it's there somewhere (because your testing is telling you so) and you know how to go about finding it.  You just need to be patient. that there's still at least one bug in your code, because it doesn't work.  So there's a chance that your testing was flawed.  So it might be worth running them again.

1 comment:

  1. And this is why you are a good programmer, my dear, while I am always in need of a second pair of eyes! Great advice, and another brilliant picture, too :)