Path: utzoo!dciem!nrcaer!sce!sunray!roberts
From: roberts@sunray.UUCP (Robert Stanley)
Newsgroups: comp.software-eng
Subject: Re: Computer Scientist Publishes 865 Errors
Message-ID: <7230@sunray.UUCP>
Date: 11 Oct 89 20:30:04 GMT
References: <8910091549.AA17481@mitre.arpa> <1989Oct10.015725.24517@agate.berkeley.edu>
Reply-To: roberts@cognos.UUCP (Robert Stanley)
Organization: Cognos Inc., Ottawa, Canada
Lines: 65

In article <1989Oct10.015725.24517@agate.berkeley.edu> bks@alfa.berkeley.edu
           (Brad Sherman) writes:
>Knuth makes at least 4 claims that some might think are contradictory
>to current SE theory.
>	(Paraphrasing from memory):
>	1) The designer should do the implementaion.
>	2) The designer should do the testing.
>	3) The designer should do the (first) user manual.
>	4) After design, implementation and user input,
>	redesign and reimplement.
>
>Is this how it's done in your shop?

If you also add in the referenced Fred Brooks quote: "Plan to throw the
first one away!"

  1) there is no better specification than a working prototype for
     communicating intent - who better than the designers to encode
     intent?

  2) The designers should certainly test the real system, but this is not
     likely to be the same implementation as they created.  Who better than
     the designers to test the system for conformance with the original
     intent and accuracy of results?  Note, this does not rule out having
     testing performed by other groups as well, but speaking as a designer
     I would be more than somewhat upset if I didn't have a hand in testing
     a production-quality implementation of one of my designs!

  3) Who else *but* the designer is qualified to write the first user
     manual, when effectively no-one else in the world knows anything
     about it?  There are two additional points, a) we are going to throw
     the first one away, but the testers of it will need a first cut at
     user documentation, and b) I heartily endorse the theory of having a
     documentation specialist on the design team.  I believe it was Apple,
     with the Macintosh documentation, who stated that if they had trouble
     writing the user documentation they sent the problem back to the
     developers...

  4) Once you have it all working to everyone's satisfaction, start again
     from scratch, using what you have as a specification, and designing a
     clean and consistent architecture to support it.  Quite frankly, given
     the enormous complexity of most of today's software, there is no other
     sane way to do it.  When I started programming, 150 assembler
     statements was a largish program.  When did you write one that small
     of late?

>Read the article!

Yes, very well worth it.  I heartily endorse the practice of keeping a
record.  My own group has found that inclusion of an automated gripe
facility also improves error reporting.  It seems that when no change of
context is required, users are more prepared to take a few moments out to
record the details of a problem when it has just occurred, and on-screen
context helps flesh out with details.  It is quite interesting to see
the consolidated gripe logs over time.  Sure helps to have all the bug
reports machine-readable from the outset, too.

I am not a bug, I am an undocumented feature.

Robert_S
-- 
 ____    ___   ___   Robert Stanley   UUCP: uunet!mitel!sce!cognos!roberts
|  _ \  / _ \ / __|  Cognos, Inc.     INET: roberts%cognos.uucp@uunet.uu.net
| |_> || |_| |\__ \  (Research)      Voice: (613) 738-1338 x6115 
|_| |_\|_| |_||___/  45 21N  75 41W    FAX: (613) 738-0002