Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!decwrl!sun!hoptoad!farren
From: farren@hoptoad.UUCP
Newsgroups: net.lang.c
Subject: Re:  questions from using lint
Message-ID: <830@hoptoad.uucp>
Date: Tue, 27-May-86 05:35:12 EDT
Article-I.D.: hoptoad.830
Posted: Tue May 27 05:35:12 1986
Date-Received: Wed, 28-May-86 04:39:42 EDT
References: <531@bu-cs.UUCP> <531@brl-smoke.ARPA> <6667@utzoo.UUCP> <1464@mmintl.UUCP> <6726@utzoo.UUCP>
Reply-To: farren@hoptoad.UUCP (Mike Farren)
Distribution: net
Organization: Nebula Consultants in San Francisco
Lines: 21


   After following a LOT of discussion about the relative merits of "design
first, then code" and "code first, then code", I have been driven to put in
my own two cents worth.  Basically, I have never worked on a project that
did not benefit (or, at least, would not have benefitted) from putting as much
time and effort into the design of the project as possible before the first 
line of code was written.  Never.  Not even once.
   By thinking about the work you are about to do before hand, you ensure
that you will probably not fall into the horrible trap of dicovering that
what you are attempting to do can't be done.  You also are preparing yourself
for the (inevitable?) eventuality that requires changing viewpoints, goals, or
the very nature of the project itself.  If you have a clear idea of where you
are going, and how you plan to get there, it's a lot easier, and less de-
moralizing, to accomodate blocks, detours, or other obstacles.  The final
product may not bear a strong resemblance to your original concept, but
at least the reason it doesn't is a *rational* one, not simply 'cause
someone panicked.

Mike Farren
{hplabs, dual, hoptoad}!well!farren
hoptoad!farren