Debugging: It's all about finding Albuquerque.

"I knew I shoulda taken that left turn at Albuquerque!"

Rico Mariani has an excellent series about The History of Visual Studio.

There's one little 'detour' in Part 10 of the story, where Rico describes debugging.

I love his description, he's clearly delivered this bit many times. It's so polished it deserves to be quoted all on its own.

I was the debugger lead in the early 90s and I used to explain the utility of debuggers and debugging tools in this way: Imagine a program with a bug, it has been running along, everything is fine, everything is going wonderful, the flow of execution arrives at a point we'll call Albuquerque, where it turns right. Now as every Bugs Bunny fan knows, the correct thing to do at Albuquerque is to turn left. The program's decision to go right has led it down an incorrect path and sometime later we will observe a problem.

Now if we're very lucky "sometime later" will be very soon, like for instance it might be that we just de-referenced a null pointer and we're going to take an exception about 2 nanoseconds after the mistake. That's an easy bug to fix. On the other hand it could be that "turning right" was more subtle - maybe we corrupted a data structure in a minor way and it might be days before we can see an observable effect - that kind of bug is a nightmare.

Finding "Albuquerque" is what I call The Fundamental Problem of Debugging. The debugger provides you with tools (e.g. breakpoints) that allow you to stop execution while things were still good and slowly approach the point where things first went wrong. The debugger likewise provides you with tools to examine the state afterwards, hoping to find evidence of what went wrong in the recent past that will help you to see the origin. The callstack window is a great example of looking at the past to try to understand what might have already gone wrong.

To find the problem, you might start after the failure and try to look back, finding a previously unobserved symptom and moving closer to the original problem or you might start before the failure and try to move forward slowly, hopefully not overshooting the problem by too much. Or you might do a combination of these things. You might add assertions or diagnostic output to help you to discover sooner that things went wrong, and give you a view of the past. It's all about finding Albuquerque.

Rico nicely covers just about all the things you do, in the desperate search for that elusive bug.

Some say too much time in the debugger is a sign of a bad programmer.

The zero-debugging viewpoint says your code should be so well designed you can reason about it without having to step into it. Others says that the best way to avoid long debugging sessions is consistent use of assertions.

I'll do whatever I can to avoid the existence of bugs in the wild. I'll use any approach I can to cut down the necessity for a deep debugging session.

But all the same, debugging is powerful magic. I expect I'll give up the Joy of Debugging when you pry the debugger from my cold, dead hands.

My book "Choose Your First Product" is available now.

It gives you 4 easy steps to find and validate a humble product idea.

Learn more.