On Wed, 20 Apr 2011 07:58:46 -0700, Darren New wrote:

> On 4/19/2011 23:02, Jim Henderson wrote:
>> It's far easier if, for instance, you're using a tool like Source
>> Navigator (which I really like for this type of thing) you are looking
>> to analyze a bug.  Having an error code and a call stack makes it far
>> easier to use a tool like that than to say "I wonder how it does 'x'"
>> and then work through the logic.  It's possible, but it can take quite
>> a while.
> 
> 
> Here's the thing about that...
> 
> There are three steps to debugging a piece of code:
> 
> 1) Find the symptoms of an error and confirm it's erroneous.
> 
> 2) Find the program state (i.e., variable values) that isn't as expected
> at that point.
> 
> 3) Trace back the infected state to the defect in the code that caused
> the original infected state.
> 
> 4) Determine how to modify the code to no longer have that defect,
> hopefully without introducing infected state that triggers an error from
> a defect existent elsewhere.

My experience (recently, anyways) is somewhat limited, but I have done 
diagnosis with code+change documentation+snavigator+error code+call 
stack.  Fairly complex software, too.

But the code in question is pretty clean and even though there's millions 
of lines of code, tracing the problem back to the root cause was pretty 
simple given the proper tools.

> An error code and a call stack gives you #1. But if you don't know what
> the program state is supposed to look like, all you have to go on is the
> actual variables that show the error message. I.e., if you don't know
> even the slightest amount of what the data in a structure is supposed to
> be, then having an error message tell you that a particular pointer is
> null when it shouldn't be doesn't help nearly as much as looking at the
> values and determining every value in the entire structure is zero when
> it should all be filled out with good data.
> 
> What's the good data?  *That* is what needs to be documented. 
> Otherwise, you're reading the code, trying to figure out what the code
> *does*, and once you do, you *still* haven't even *started* to find the
> bug. Then you have to guess what the author *intended* to have happening
> there, and then guess from that what the state should have been. *Now*
> you've finished step #1. With documentation, all that is tremendously
> simplified or eliminated, depending on how detailed the documentation
> is.
> 
> Saying "the code is the documentation" is like saying "the commercial
> airliner doesn't need maintenance documentation. You can just look at it
> and see what's wrong."

I have to admit I like that way of looking at it. :)

Jim

Post a reply to this message