Comments on book review

Henry Spencer henry at utzoo.UUCP
Sat May 12 06:24:14 AEST 1984

Doug Gwyn comments, in part:

   It is the job of the analyst to properly define the problem to be
   solved, among other things.  Perhaps there is simply not enough
   care being taken with problem definition before program design

Sorry, Doug, but to my mind the whole role of the "systems analyst" is
part of the "software development cycle" mythology:  "of course we can
get it right the first time".  Nonsense.  The whole idea of "properly
defin[ing] the problem to be solved" implies that the nature of the
problem can be nailed down once and for all beforehand.  For the main
reason why this doesn't work, see my previous comments about users'
views of the problem changing once they are exposed to a first-draft

Mind you, I agree that properly defining the problem to be solved is
important.  Lack of effort towards this has led to a number of pieces
of software that "solve" important problems in thoroughly brain-damaged
ways; Berkeley job control comes to mind.  [Before I get roasted from
all sides, let me urge job-control enthusiasts to re-read that last
sentence carefully:  I'm not saying that job control isn't useful, but
that the importance of solving the problem (orderly interaction with
multiple simultaneous processes) has blinded people to the fact that
Berkeley solved it very poorly.]  My point is that the insight needed
to understand problems comes from experimenting with solutions (with,
preferably, real users as the experimentees), not from abstract
contemplation of specifications.
				Henry Spencer @ U of Toronto Zoology

More information about the Comp.lang.c mailing list