There truly isn’t.
Either you have your health or you don’t. If you have your health you only have two things to worry about, whether you live or die. If you live you have nothing to worry about. If you die you only have two things to worry about, whether you go to heaven or hell. If you go to heaven you have nothing to worry about. If you got to hell you’ll be so busy having fun with your friends you’ll have nothing to worry about!
Which brings me to my favorite topic. Debugging. I like to think I’m pretty good at it. Probably because I have written and debugged thousands of programs since I started programming Z-80 assembly language on my Radio Shack TRS-80. Or maybe because I just write a lot of programs with bugs. Either way, it’s forced me to be a good debugger.
Programs either work or they don’t. But what does “work” mean? Software, although it rarely does, can work ALL of the time. If it doesn’t work ALL of the time it might NEVER work. Those are the two extreme possibilities. The program fails consistently or it just always works (as much as you can test).
Then there is the gray middle — the program might fail on exactly 1 case. Or it might fail on a set of cases (N) that all fall into a well defined category . For example your algorithm does not work with negative values. It’s also possible that your program has environmental constraints — it might not work when the moon is full, there are resource issues or other programs, the operating system or outside agents create an environment (without intent) that negatively effects your program. It’s the latter situations that are the most difficult because they appear to be random.
If you subscribe to the philosophy of Causality (and you must if you want to be a good debugger), there is no ghost in the machine. All bugs have a cause. Well that’s not quite true — they may have many causes…and don’t forget that bugs sometimes come in sets and fixing one bug may expose another! It’s not uncommon to find mutually dependent bugs…bugs that work together to create a defect or an even stranger spookiness at a distance is created when two incorrect pieces of code conspire to somehow manage to “do the right thing”!
Debugging is a science (with a touch of artistic creativity sometimes). There are some general principles that guide good debugging. David Agans has a wonderful little book that every developer should read (again and again). His 9 rules are captured neatly in his poster you can find here.
Understand the system
Make it fail
Quit thinking and look
Divide and conquer
Change one thing at the time
Keep an audit trail
Check the plug
Get a fresh view
If you didn’t fix it, it ain’t fixed
By the way, these rules are not randomly ordered. A failure to execute the first rule makes debugging an exercise in frobnostication or “frobbing” — the seemingly mindless act of pressing buttons, turning knobs and dials without actually knowing what turning it on, left or right might do with the “hope” that the program will suddenly work. Hope is not a strategy.
While as dumb as “frobbing” may seem, it does have a place in troubleshooting. So, when is it time to frob?
- It’s difficult, impossible or there’s no time to “understand the system”.
- You can’t make it fail consistently.
- You can’t look — you don’t have access to enough of the code, the environment or the data.
Even so, you still can:
- Divide and conquer
- Change one thing at a time
- Keep an audit trail
- Check the plug
- Get a fresh view
Of all of these I have found that it is best to enlist the aid of another experienced troubleshooter before the frobbing begins. Even if they understand the system less than you, an experienced debugger will systematically keep both of you sane — and if you are frobbing feverishly it’s more than likely they will have creative ideas about what dials and knobs one can turn. They may even prevent you from pressing the panic button or worse yet, the one that launches the warheads.
So there you have it. Use the 9 steps to troubleshoot and debug. When all else fails feel free to frob away, but bring a friend along for the adventure!
