home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / software / 4420 < prev    next >
Encoding:
Text File  |  1992-11-19  |  1.4 KB  |  31 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!magnus.acs.ohio-state.edu!csn!raven!rcd
  3. From: rcd@raven.eklektix.com (Dick Dunn)
  4. Subject: Re: Will we keep ignoring this productivity issue?
  5. Message-ID: <1992Nov20.070133@eklektix.com>
  6. Organization: eklektix - Boulder, Colorado
  7. References: <17556@mindlink.bc.ca> <1992Nov18.114414.9296@iccgcc.decnet.ab.com> <1992Nov18.205130.13951@ultra.com>
  8. Date: Fri, 20 Nov 1992 07:01:33 GMT
  9. Lines: 20
  10.  
  11. jerbil@ultra.com (Joseph Beckenbach) writes:
  12. >Gerry_Furseth@mindlink.bc.ca (Gerry Furseth) writes:
  13. >> Aphorism: If you can't write a testing plan from your design, the resulting
  14. >>           code will be unreliable.
  15. >
  16. >    Ideally you're refining the test plan while doing the design;...etc...
  17.  
  18. These guidelines get more complicated if you start writing code first and
  19. derive the design from experience using the code.  In that case, the
  20. evolving code tends to be in the driver's seat--not so much because the
  21. design is subsidiary as because it's lagging behind.  The test plan then
  22. gets to chase both of them.
  23.  
  24. (It's always a chase anyway, except in the rare cases when you get one of
  25. those delightful projects where the specs hold still through the imple-
  26. mentation.  But code chasing specs is a lot more common, hence [I think]
  27. less unnerving.)
  28. -- 
  29. Dick Dunn    rcd@raven.eklektix.com   -or-   raven!rcd    Boulder, Colorado
  30.     ...Simpler is better.
  31.