>Hi Nancy,
>
>>Once I get to this point, btw, I'm not in debugging mode any more. I step >back, in this case, to design mode.
>
>This is the key, here. So you keep DEBUG associated directly with coding, and not with design/discovery?

Right. It seems simple, but I've found it really makes a difference if I consciously think about what my role is at any particular time. Am I designing? Am I testing? Is it time to take the trash out? Oh, wait, that's when I'm acting as PDI janitor. ;-)

>>Why is it important to make that distinction? I don't know about you, but >for a lot of us, there's a tendancy to do other things while debugging. >Like, you notice something in some code as you're looking for problem A. So >you change code, then you change what you originally meant to change for >debugging, then you test your code, and suddenly, it's different. You >unfortunately have tainted your investigation.
>
>This became one of the debugging errors(!) I used to make. I've killed myself with this so many times that I classify this as completely incorrect behavior when bug-hunting. I've been trying to get into the habit of strictly avoiding this. Now if I see something I think should change, I add it to the task list. I try to allow no changes until the debug session is finished.

Yes, this requires a lot of self-discipline. But I've gotten myself in such straights that I ended up wasting a lot of time.

>The harder part is to make my associates understand this as well.

Educating people about the value of debugging and the value of a good process is one of my pet projects, obviously. I quote a bunch of statistics in my book that I gleaned from other sources about testing and the cost of bugs and so...but it's _still_ hard to convince people to support a good process. Even when they intellectually +agree+!

>Try catching a bug when someone else is modifying files dependant to the one you're debugging! Hard to track, especially if there is no source control to 'check out' the files with to keep them locked.

Oi! That is really tough. That's when I like the idea of developers working on their own copies of the source. Too bad about the source code control. Sounds like something that would help your situation generally. But that's another digression, eh? < g >

>>I've found I get less distracted from my priorities, too, if I'm >methodical.
>
>This is very true!

And, so I should probably get back to them. ;-) Thanks for the interesting comments.