Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!primerd!primerd!os
From: os@primerd.prime.com
Newsgroups: comp.sys.mac.programmer
Subject: Know What You Are Doing
Message-ID: <49900005@primerd>
Date: 30 Mar 91 00:07:51 GMT
Lines: 68
Nf-ID: #N:primerd:49900005:000:3664
Nf-From: primerd.prime.com!os    Mar 29 12:18:00 1991


I have been reading a book recently, "C Traps and Pitfalls" by Andrew Koenig.
I would recommend to anyone.  The concluding chapter opens with the following,
which struck a chord with me and I'd like to share:

-------------------------------------------------------------------------------

    You have just finished a tour through some of the ways that C program-
    mers can hurt themselves.  Like many of the people who read early drafts
    of this book, you are probably wondering:  "How can I avoid these prob-
    lems?"

    Perhaps the most important avoidance technique is to <<know what you're
    doing.>>  The most irritating problems stem from programs that appear to
    work but have hidden problems.  Because these problems are hidden, the
    easiest way to detect them is by careful thought in advance.  Fiddling
    with a program until it appears to work is a reliable way of obtaining a
    program that almost works.

    The most eloquent statement of this I have seen appears, of all places,
    in the construction manual for a harpsichord.  It was written by David
    Jacques Way, who clearly appreciates the importance of confident
    knowledge, and with whose kind permission I reprint it:

         'Thinking' is the cause of all error;  I can prove this by
         the fact that whoever makes a mistake always says, "Oh, but
         I thought...."  Never mind this kind of thinking - before you
         glue anything together you must know.  Put the parts together
         without glue (called a 'dry run'), study how they fit, and
         check with your drawing, which shows how everything fits.

         And after you have put something together with glue, check
         it again.  I've heard the sad story so many times:  "Last
         night I did so and so, and this morning when I looked at it...."

         Dear builder, if you had looked at it last night you could
         still have taken it apart and put things right.  Many of you
         are building in your spare time, so the temptation is great
         to work far into the night.  But if I can believe my tele-
         phone calls, most mistakes are made the last thing before
         you go to bed.  So go to bed before you do the last thing.

    This advice is remarkably relevant to programming if one thinks of
    "putting it together with glue" as combining several small pieces into
    a bigger program.  Understanding how the pieces are going to fit
    before actually fitting them is one of the keys to a reliable result.

    Such understanding is particularly important under time pressure.
    Near the end of a long debugging session, it becomes tempting to try
    things almost at random and stop as soon as something seems to work.
    That way lies disaster.

-------------------------------------------------------------------------------

My own comments are along the opening line of <<know what you are doing.>>
Back in the old days people used to walk through their code offline.  Now
we often twiddle until it compiles and the step thru with a debugger until
it works.  We don't step back, offline, with a paper listing in hand to review
things by ourselves in a methodical manner.  Some may reply that they are
covered by having an individual or a team perform a code review or code
inspection, but I claim that is too late.  I want to be sure of things on
my own time, to know it cold, inside and out, both within a module and at
the overall system (of modules) level, before I waste someone else's time.
I want to know what I am doing.

Jim Cook
Prime Computer, Inc.
<J.Cook@ENS.Prime.COM>  (Don't email to os@primerd).