Messages in this thread | | | Date | Wed, 06 Sep 2000 21:48:20 -0700 | From | Stephen Satchell <> | Subject | We are as good as our tools |
| |
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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |