All software of sufficient complexity to do something useful (and even some that don’t do anything interesting at all) will contain bugs. This is a fact of life.

It’s the job of the programmer to find and remove these bugs. There are many ways of going about this but the most interesting, I think, is using a tool called a debugger.

If you’re a doctor, probably the best diagnostic tool you could imagine is to take a patient and cut them open and watch their innards move around, undisturbed, as they go about their daily lives. Imagine you could puncture a huge hole in someone’s chest to examine their heart and lungs while they sit there in the consulting room, chatting away amiably.

Unfortunately for the medical profession, people tend to cry out in great torment, flop on the floor and bleed everywhere if you do all that. (Though something very similar does come up in Use of Weapons by Iain M Banks, where it’s used as a party gimmick!) But programmers can get away with it.

A debugger is a tool that lets us run programs with their innards on display to the world. If something bad happens we can rewind to see what conditions caused it. We can see the last actions of the program before it did something stupid. Why did the user’s high score suddenly change to -2147483648? Why does it crash every time I click Save?

The debugger will even let you ‘run’ the program in discrete steps, like advancing a frame at a time. Or you can pause the program whenever you need — on every autosave, or every new wave of aliens, or just as the whim takes you.

If you see a problem you can tinker with the program as it runs. It would be like your doctor reaching in to ‘fix’ up your plaque-hardened arteries while you are in suspended animation, then releasing you to see how you feel. Pretty neat.

Debuggers are not much use outside the programming field. In fact, they’re one of these specialised tools that people can’t even imagine until they’ve seen one. But they’re also extremely cool, which is what counts.

If you were paying attention to the field of pseudoscience a couple of weeks ago you’ll remember the story of the maths teacher who revolutionised division by zero and without a by-your-leave was teaching it to secondary school pupils. Not only was he subverting the standard procedure of childhood education (by teaching his pet fantasies as the next great Truth) he was also talking a load of cobblers.

His point rests on the unfortunate fact of there not being an answer for division by zero. In fact, it’s defined as not being answerable. In computer programming this has the unfortunate result of occasionally causing a problem or two. Division doesn’t get used in maths or programming as much as, for example, addition but it does pop up. What was your average score for all the games you’ve played? Well, add up all the scores and divide by the number of games.

But what if you’ve only just installed the software and the number of games played = zero. What then is the average, since we cannot divide by zero? This problem is easy enough to predict and avoid: we only calculate the average if there’s been at least one game played. Some circumstances are less easy to predict, and sometimes the programmer just plain forgets to check.

The result of division by zero is an error. This error is named Not a Number, or NaN for short. If the programmer commits such a faux pas then two things will happen. The program may follow Elvis and “leave the building”, which will often result in a little dialog box in Windows saying the program attempted a division by zero.

The other thing that happens — and this is, I think, more common in languages which don’t mind about well-typed results — is that “NaN” is rendered as a literal result. So the average score over the last zero games played is… NaN.

Just to illustrate the point, codeman38 kindly allowed me to use the weather widget shown. The person who wrote this obviously didn’t check for the presence of zeroes before dividing and the result is as you see — very silly.