Comments on book review

[Doug Gwyn]

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