Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.lang.c
Subject: Re:  questions from using lint
Message-ID: <6667@utzoo.UUCP>
Date: Thu, 8-May-86 15:14:59 EDT
Article-I.D.: utzoo.6667
Posted: Thu May  8 15:14:59 1986
Date-Received: Thu, 8-May-86 15:14:59 EDT
References: <531@bu-cs.UUCP>, <531@brl-smoke.ARPA>
Organization: U of Toronto Zoology
Lines: 36

> All too often, one sees programmers writing code before
> a proper job of analysis and design has been done.  I
> also believe that is partly because semi-running code
> makes it appear as though progress has been made,
> while a complete design doesn't convey the same impression.

Sorry, Doug, I can't let that one go by.

All too often, one sees programmers writing detailed design specifications
before writing any code.  This is probably because design specs make it
appear that the problem is fully understood, and give the impression to
management that the rest of the process of implementation will be entirely
mechanical and hence will be on budget and on schedule.  Ho ho.  Then one
gets to draw up a new budget and schedule for "maintenance", which is the
process of modifying the program so that it really meets the customer's
needs, instead of merely meeting the specification.

The alternative is to recognize that (a) the user probably does not have
a complete and coherent idea of what he needs, and hence cannot write a
spec or meaningfully assess one you write, and (b) in any case, the presence
of the software itself will change the user's tasks and therefore his needs.
Given recognition of this situation, it is not even theoretically possible
to avoid a trial-and-error process of software development.  Hence you
should aim to make your inevitable mistakes as early as possible.  Which
puts a heavy premium on getting initial prototype software into the hands
of the customers right away, so that you can learn what's wrong with it.
One progresses by iteratively enhancing (and perhaps sometimes re-doing)
the prototype, with regular user feedback.

This is not to say that the design-it-first method doesn't have its uses,
and its advantages, when the problem is understood well enough.  But a very
large class of problems -- almost anything to do with user interaction, for
example -- simply don't meet that criterion.
-- 
Join STRAW: the Society To	Henry Spencer @ U of Toronto Zoology
Revile Ada Wholeheartedly	{allegra,ihnp4,decvax,pyramid}!utzoo!henry