At 06:40 PM 9/6/00 -0700, J. Dow wrote:
>30 years of experience have proven this to me over and over again from
>watching auto mechanics and ditch diggers through every engineering
>discipline I have ever paused to observe. Only a damnfool eschews good
>tools because of some sense of "pride" that doing it the caveman way
>"forces me to think more."
Let me add my 30-year's worth of experience in a number of nasty computer
environments to Ms. Dow's comments. There are seven people in the world
who I drove crazy by paying more attention to tools than to the "task at
hand"... yet when it came to counting coup on projects that WORKED, my
bosses quickly shut up about my building jigs and scaffolding and debug
aids into code.
In other parts of the Open Source community, people point with pride to the
tools they use to do their work. Let's not forget that Ritchie decided
that he needed a language to speed his development of a quick-n-dirty
operating system using an old PDP-7 that had been discarded -- when the
"logical" way would have been to dig right in -- using assembler, the
language of the day, to try to get the job done. Interesting that the tool
came first, in the system that gave birth to the effort which is the
subject of this mailing list...
On the subject of debuggers: All too often I have run into the situation
with real-time code where the Heisenberg principle causes the system to
work with the debugger in, and fail with the debugger out. Ditto with
"test code" that is conditionally compiled as an aid to debugging. It's
akin to a hardware engineer using 50pF capacitors to "make the prototype
work" and never taking the time to understand just why adding a touch of
slowdown made the circuit work.
This is especially true when that "50pF capacitor" is a scope probe.
Is that a good reason to "just say no" to debuggers? I don't think
so. Too little reliance on debuggers and defensive code is just as bad, if
not worse, than too much reliance. Debuggers are great for collecting the
symptoms of the problem; it still takes thinking and role-playing to get to
the heart of the problem. That thinking operator also has to know the
effect of the tool he is using, just as the hardware guy has to know the
effect of placing a scope probe right THERE on the circuit. Indeed, that
scope probe can be a handy way to tweaking the system in subtle ways, and
with analysis of the change in the symptoms that can point to the
problem. "Why does placing a breakpoint THERE cause such a drastic
change? AHA!"
With the amount of state being thrown around in an operating system, only a
good debugger in the hands of a thinking operator can isolate the fault to
a particular block of code -- then the thinking operator gets off the
machine and onto the source code to noodle out why the astonishing event is
occurring.
I'll crawl back into my writing cave now, content to watch for the moment.
Satch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
