Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ut-sally!husc6!cmcl2!rutgers!ames!ptsfa!ihnp4!cuae2!killer!elg
From: elg@killer.UUCP (Eric Green)
Newsgroups: comp.sys.amiga
Subject: Re: Structured Design (Not a marketing analysis)
Message-ID: <1267@killer.UUCP>
Date: Sat, 1-Aug-87 03:12:07 EDT
Article-I.D.: killer.1267
Posted: Sat Aug  1 03:12:07 1987
Date-Received: Sun, 2-Aug-87 09:58:15 EDT
References: <469@cc5.bbn.com.BBN.COM>
Organization: Bayou Telecommunications
Lines: 58

in article <469@cc5.bbn.com.BBN.COM>, denbeste@cc5.bbn.com.BBN.COM (Steven Den Beste) says:
> Answer 3: Design it completely before you code it.

Easier said than done. You have to design it using SOME language, after all!
Considering that a lot of these programmers know more Fortran than English....
:-) :-) :-) :-).

> A. SPECIFICATION: Write the user manual FIRST!! [I'm not kidding! Figure
>    out what you are going to do before you start working on any of it! Not
>    doing this is THE classic novice's mistake.]

Definitely! AMEN! Too often, the documentation is put off, with "well, we can
do that later, we're too busy programming right now".... and someone wonders
why the user manual is delaying the project, and why there's awkward errors in
the user manual (answer: the documentation folks were writing the manual at
the same time the programmers were writing the program, and there's no way for
the commmunications to be tight enuf for the left hand to know what the right
is doing!). 

> B. ARCHITECTURE: Figure out the functional breakdown and DOCUMENT IT.

Hmm.... a lot of the time, you don't KNOW what the architecture of the program
is going to be like, until you have sketched out some major algorithms and
data structures.... But, still, in general, this is good advise.

> C. DETAILED DESIGN: FIgure out precisely what every module and data structure
>    is and DOCUMENT IT.

Hmm. Here's where I start seeing diminishing returns. You are essentially
programming in English instead of in "C" when you reach this point. And, as I
mentioned, most programmers are more comfortable with "C" than with English.
in general, I don't advocate a level of pre-coding design more complex than
breaking the project down into man-sized chunks, and describing the major data
structures and algorithms involved, and the major routines and their interface
requirements. A well-designed project consists of a number of black boxes,
with designer of one box having no need to know the contents of another box.
Excruciatingly precise design documents of box internals therefore would be
self-defeating, burying the poor programmer in tons of stuff he doesn't need
to know. Requiring internal documentation of every module and data structure
describing its purpoe, range of values, and parameters is MUCH more useful,
espcially if the documentation is in a special format such that it can be
easily extracted via a "sed" script or such in order to make a master
interface manual....

> to fit it together later. The usual objection of a traditional programmer to
> Structured design is "I'm a programmer - I'm here to code. Why the hell do you
> want me to do all that useless documentation?"

Because I'm always looking for an easier and faster way of doing things. I get
tired of working on the same old project month after month, and have been
known to go to ridiculous lengths to find just the right tools to make my job
easier, so I can go on to newer and better things.

--
Eric Green   elg%usl.CSNET     Ollie North for President:
{cbosgd,ihnp4}!killer!elg      A man we can believe (in).
Snail Mail P.O. Box 92191      
Lafayette, LA 70509            BBS phone #: 318-984-3854  300/1200 baud