I’m afraid I don’t have an example easily to hand at the moment. Sometimes fixing a bug requires just making a change to code: “<” becomes “<=” and the test passes. Sometimes, though, fixing a bug requires a change to the design first: I’m performing this conditional in B, but I need to perform it in A before B ever gets called. In this case I divide the fix into two phases, changing the design and then fixing the bug. The debugger and in particular the stack helps me in the first phase.

I’ll try to catch myself the next time I do this and write it up in detail.

“Most problems are fixed by moving logic up or down the stack.
…
solutions (most often involving moving logic up or down the stack)…”

Wait, what?

Do you mean fixing bugs involves this, or that fixing the design does? I can kind of see that moving responsibilities between two classes that call (methods on) each other corresponds to “moving logic up or down the stack”.

A concrete example would help me understand this point.

Later on when Kent and others began writing books on XP, I was introduced to the concept of unit testing. What I began to realize at that time was that using the debugger was great on the first pass, but when you had to deliver lots and lots of versions it became very inefficient to have to re-visit the debugger. I then came across numerous colleagues who would tell me that I was wasting my time in the debugger that I should be writing unit tests and those unit tests would solve all of my problems. I began writing unit tests fairly heavily on larger projects but something wasn’t right if I didn’t spend time in the debugger too. I knew that it was necessary but was just too busy to worry about why. I think the answer is that I was designing on that first pass. I design in the debugger minimally on a first pass and often times even further along than that. The unit tests were necessary to reduce the amount of time I would have to spend in the debugger on successive passes and as the code grew this became more important. I might step through the debugger only in new pieces of code or rarely in older pieces. However, the unit tests would fail and catch huge errors caused by minor changes without me having to retrace through every line of code I had ever written on the given project. I find that use of the debugger while coding, as opposed to when debugging has saved me more time than any other tool in my skill set. Unit testing is second. I need all that extra time… to spend with my kids.

If there’s anyone else out there whose experienced this I’d love to know because I usually feel pretty alone.

Nowadays 64K instructions is nothing, but at the time it was like a time-machine. From the point your program crashed (or where you put your break-point) you could go way back to see how it actually got there.

I wonder if the Java VM could be tricked into doing something like that.

A few years ago I worked on extending Sun’s Javac compiler. As I was working I noticed that I am using the debugger to understand the design much more often than the raw source code.

In the automotive industry a lot of effort is put in making cars safe and even safer. But crash tests are the proof of the behaviour of the designed safety precautions built into a car. The results of the crash test show how the components behave. Video caps and sensor data are used to analyse the movement of parts in the car.
Walking through the vid caps and sensor data will give engineers information on how to redesign or recreate parts.

This is exactly what debugging is about in software. Replaying the scenario over and over until you ‘see’ what the problem is. You then decide to redesign or refactor or just fix the bug.

Now, isn’t that beautiful?

It has become for me a way to evalute the skills of a developer; how good is he at debugging? how fast is he at finding a bug using a debugger? Usually, people with good debugging skills are also quite efficient at writing “good” code (but maybe it is only because they’re more dedicated to development).

Otherwise, it seems true for me that the use of a debugger can help in your design by giving you another point of view, rather than just looking at plain code; having an idea of what’s in the context of your application at some point can help you to easily check that the code is behaving the way you want it.