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.
'KristofU' on Fri, 06 Nov 2009 06:55:29 GMT, sez:
Murphy's Law for asserts :
The more an assert seems obvious and superfluous, the higher the chance that it will be triggered.
'Ben F Rayfield' on Fri, 06 Nov 2009 20:35:16 GMT, sez:
Theres a much easier way to find bugs...
If you are a person who writes bugs and fixes them later, then you are fixing the wrong bugs. Yourself is the bug that caused those bugs. The most effective way to fix that bug is to go learn logic, bayesian statistics, and things like that.
I would not take a code-generating software seriously if it generated code that contained bugs. A programmer is a code-generator.
'Boofus McGoofus' on Fri, 06 Nov 2009 21:30:59 GMT, sez:
First step in figuring out what legacy code does: run it through the debugger and watch what happens. Stepping through code is a great way to learn what it does. While that's not tough to do with pen and paper, it's even easier when the debugger does it for you.
'Vincent Vancalbergh' on Wed, 15 Jun 2011 15:10:06 GMT, sez:
PS: I read the legal bit :D
Downtime as a service
The Shape of Your Irrationality
This is why I don't go to nice restaurants any more.
A flowchart of what programmers do at work all day
The Telepresent Man.
Interview with an Ex-Microsoftie.
CRUMBS! Commandline navigation tool for Powershell
Little tool for making Amazon affiliate links
Extracting a Trello board as markdown
hgs: Manage Lots of Mercurial Projects Simultaneously
You Must Get It!
AddDays: A Very Simple Date Calculator
Google caught in a lie.
NimbleText 2.0: More Than Twice The Price!
A Computer Simulation of Creative Work, or 'How To Get Nothing Done'
NimbleText 1.9 -- BoomTown!
**This** is how you pivot
Art of the command-line helper
Go and read a book.
Slurp up mega-traffic by writing scalable, timeless search-bait
Do *NOT* try this Hacking Script at home
The 'Should I automate it?' Calculator
Complete secretGeek Archives
TimeSnapper: automatic screenshot journal
25 steps for building a Micro-ISV
3 Minute Guide Series
Universal Troubleshooting Checklist
Top 10 SecretGeek articles
Now at CodePlex
RealTime Online CSS Editor
How to be depressed
You are not inadequate.
the little schemer
The Best Software Writing I
The Business Of Software (Eric Sink)
InfoText - amazing search for SharePoint
LogEnvy - event logs made sexy
Computer, Unlocked. A rapid computer customization resource
BrisParks :: best parks for kids in brisbane
PhysioTec, Brisbane Specialist Physiotherapy & Pilates