[lkml]   [2000]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectWe 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

    I'll crawl back into my writing cave now, content to watch for the moment.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:38    [W:3.383 / U:0.156 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site