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.

It is an impossible task to tell whether a program will run for a very long time, or run forever. If it’s been running for twenty minutes, it may be just about finished. Or it may need twenty years. It may need twenty thousand years.

Or it could just be spinning its wheels in the mud, working furiously on nothing in particular. This could be because of problems outside the program itself — a browser will appear to be doing nothing if you try to access the web when you’ve not got internet access. That is no fault of the program, or its programmer.

But there are infinite loops which a programmer can cause. There are a good number of times where a programmer will start off a series of tasks but not check if the task is finished. This problem has been immortalised on film in Fantasia with poor Mickey Mouse as the inept programmer.

For those lucky poor folk who don’t know the story of the sorceror’s apprentice it goes like this. Mickey is the apprentice to a powerful wizard, and like all apprentices (Karate Kid, Wizard of Earthsea) spends most of his time doing drudge work. He’s tasked with fetching water from the well and — while his master is away — attempts to use magic to save effort.

He programs a broom to come to life and carry in the pails of water while he has a snooze. Alas, Mickey makes a schoolboy error — he sets off an infinite loop. The animated broom has no concept of when to stop and continues to bring water into the house until the floor becomes flooded.

The lesson could well be learned from this but I’m not satisfied. We can take the analogy further (for no good reason). Mickey cannot stop the magic broom so smashes it to pieces with an axe. Each piece jumps into life, grows arms and legs and picks up a bucket for itself.

In computer terms the hapless apprentice spawned dozens of non-terminating programs from his original one. What a mistake! Luckily the system administrator sorceror came back at the right moment to kill all the magic broomsticks.