Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!caip!seismo!harvard!bu-cs!bzs
From: bzs@bu-cs.UUCP (Barry Shein)
Newsgroups: net.lang.c
Subject: Re:  questions from using lint
Message-ID: <666@bu-cs.UUCP>
Date: Sun, 25-May-86 14:41:16 EDT
Article-I.D.: bu-cs.666
Posted: Sun May 25 14:41:16 1986
Date-Received: Tue, 27-May-86 06:33:33 EDT
Organization: Boston Univ Comp. Sci.
Lines: 69


Re: To design then code, code then design, a little of each iteratively? etc.

Obviously it depends on the problem, let's ignore the trivial cases.

One major consideration to always take into account is "who is the customer?"

When I am programming something by request/contract of someone else
a whole different set of rules come into play. Before I start coding
the User's Manual is written, delivered to the 'customer' and agreed
to, preferably in writing.

99% of the heartache I've encountered in coding for someone else had
to do with delivering the more or less finished product and having
the "customer" suddenly get this surge of creativity upon playing
with the program (gee, why can't you make a "few little changes" to...)

At least I can point to the User's Manual that was signed off and possibly
at that point offer to negotiate a new project. They don't like it, but
they can usually understand it.

If there are other potential complexities I would go for a Maintainer's
(or System Administrator's) guide. This was important in one case where
I was building a data-base system and I sincerely felt they did not
understand that they needed more disk to do what they wanted. I sent
over some pre-docs with "worksheets" to estimate disk needs and asked
them to please have someone work through them with me a little as in
conversations I saw them waving their hands and all they seemed to
be thinking about was the price of the disk(s).

And so on...

I think the most dangerous thing that happens to a program that did
not have enough aforethought is the sudden realization that the
data structure(s) involved were not powerful enough to do the job,
this can ripple through an entire software system and practically
require ground-up re-write. I've had it happen.

With the hope of not immediately starting the obvious flame-fest,
people who code in FORTRAN are most liable to this failure as they are
strongly motivated to make every problem work in terms of scalars and
arrays.  Not that they *can't* represent a binary tree, but because of
the unnaturalness of that in FORTRAN they will tend to try to ignore
that option until it is too late. Often if FORTRAN is their only
language they aren't very sophisticated in recognizing the problem,
but that's another issue.

Generally, in a reasonably well-coded program the algorithms are fairly
easy to replace (how hard would it be to change sort methods for example)
as it involves re-writing a specific module and generally leaving the rest
alone. A change in data structures, however, can almost never be localized
in effect. At the very least, besides the issue at hand, input and output
(and storage/retrieval) routines usually have to be re-written.

The conclusion would be, therefore, design your data structures carefully
and with aforethought. If you don't want to design all the algorithms
beforehand keep things modular and recognize what pieces you may want
to replace later.

TRAP: Changing the algorithm CAN sometimes demand changing the data structure.

When in doubt, sketch it out.

In defense of the iterative process this is often actually used to
explore possibilities to use in the design. If the code used in the
"experiments" happens to get used in the final project, all the
more better, but don't let the tail wag the dog.

	-Barry Shein, Boston University