Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!akgua!sdcsvax!dcdwest!ittvax!decvax!harpo!seismo!brl-tgr!brl-vgr!gwyn
From: gwyn@brl-vgr.UUCP
Newsgroups: net.lang.c
Subject: Re: Comments on book review
Message-ID: <2003@brl-vgr.UUCP>
Date: Mon, 14-May-84 14:16:22 EDT
Article-I.D.: brl-vgr.2003
Posted: Mon May 14 14:16:22 1984
Date-Received: Wed, 16-May-84 07:37:52 EDT
References: cubsvax.219, <2414@ecsvax.UUCP> <3231@fortune.UUCP>, <447@opus.UUCP>, <1515@brl-vgr.ARPA>, <3838@utzRe: Comments on
Lines: 27

Relay-Version: version B 2.10.1 6/24/83; site decvax.UUCP
Posting-Version: version B 2.10.1 6/24/83; site brl-vgr.ARPA
Message-ID: <2003@brl-vgr.ARPA>
Date: Mon, 14-May-84 11:16:22 EDT

 book review
Organization: Ballistics Research Lab
Lines: 18

I suspect we are more in agreement than it appears.  By suggesting that
a professional software designer get involved in problem definition
before the solution is designed, I do not mean ANY sort of irrelevant
abstraction.  Through good communication with the clients of the
software system being designed, and after careful study of their
current and expected methods and requirements, one should be able to
ITERATIVELY present system designs (data flow diagrams and other
documents that the clients can COMPREHEND) and work with the clients to
make sure that what is going to be built is in fact what is really
needed.  Then later, when requirements change (as they will), the
original design documents serve as the starting point for discussion
of what to change in the system and how it affects the overall
operation.

The few times I have seen this tried it has been substantially more
successful than either older traditional design approaches or hacker
design.  (MY definition of a hacker is a person whose attempt to
solve a problem is to immediately start writing code.)