Comments on book review

[Henry Spencer]

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

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

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
				{allegra,ihnp4,linus,decvax}!utzoo!henry