Comments on book review

gwyn at brl-vgr.UUCP gwyn at brl-vgr.UUCP
Tue May 15 04:16:22 AEST 1984

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 at 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

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.)

More information about the Comp.lang.c mailing list