The great thing about this technique is that it is literally applicable to any situation - regardless of what debugging tools you have available, or even what languages and technologies you may be using, you can always find a variant of this technique that can be useful.
I personally refer to this method as writing event sequence notes. The name should pretty much give away the gist of the technique: the goal is to write down a step-by-step analysis of everything that happens in the code.
Well, you may ask, why not just read the code? What's the point of writing down this event sequence if the code itself already explains what should happen?
The magic word there is "should" - as we all know, debugging is essentially the process of finding out the difference between what does happen and what should happen.
Of course this technique is easiest when you have a debugger and can step through the code in question; but, failing that, using debug logging can be just as effective. Just be sure to log every detail, even if it doesn't seem relevant.
A good event sequence log will show a history of what code is executed; but it will also record key variable values and other state information. Further, you should write the events in prose rather than code. This forces you to really think about what each line of code has done as it gets executed. The net result is that you have a perfect description of how the program gets into a buggy situation.
This technique can be immensely helpful when dealing with very large or complex code bases, because you can prune away all the code that didn't happen and focus entirely on what code is getting executed. It's a method for filtering out distractions and irrelevant data, which helps keep the scope of the debugging challenge under control.
So there you have it. This probably isn't news to seasoned debuggery artists, but hopefully it will be of some use to somebody [smile]
Tools like PIX for Windows offer some great insight here when dealing with D3D programming. You can record the event sequence of your app and then step through it to see what actually happened which is ultimately more important than what your multi-layered abstraction sitting on top of the API should be doing...
I was wondering recently if there was any way of inserting trace tags and reverse engineering a UML sequence diagram from code. I like visually drawing flowcharts and diagrams for this style of debugging and a tool would be pretty darned cool [cool]
Jack