home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / software / 4482 < prev    next >
Encoding:
Text File  |  1992-11-23  |  1.9 KB  |  46 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!caen!batcomputer!cornell!rochester!rit!mjl
  3. From: mjl@cs.rit.edu (Michael J Lutz)
  4. Subject: Re: productivity "vs" predictability
  5. Message-ID: <1992Nov23.220350.2816@cs.rit.edu>
  6. Sender: news@cs.rit.edu
  7. Nntp-Posting-Host: prague
  8. Reply-To: mjl@cs.rit.edu
  9. Organization: Rochester Institute of Technology
  10. References: <1992Nov11.055130@eklektix.com> <1992Nov16.160026.7548@athena.mit.edu> <1992Nov16.195049.12628@athena.mit.edu> <1992Nov20.065254@eklektix.com>
  11. Date: Mon, 23 Nov 1992 22:03:50 GMT
  12. Lines: 32
  13.  
  14. In article <1992Nov20.065254@eklektix.com>, rcd@raven.eklektix.com (Dick Dunn) writes:
  15. |> tada@athena.mit.edu (Michael J Zehr) brought up an interesting point out of
  16. |> the productivity discussion:
  17. |> >It seems like part of the problem is that software engineers would like
  18. |> >to increase productivity, but software managers would like to increse
  19. |> >predictability.  
  20. |> It's possible to get productivity and predictability completely at odds
  21. |> with one another.  It doesn't happen in the extreme a lot, but there's more
  22. |> of it than there should be:  *One* way to increase predictability is simply
  23. |> to add a measure of make-work to the project--which doesn't serve any real
  24. |> purpose, but makes the variability part of a larger overall number, hence a
  25. |> smaller fraction.
  26.  
  27. I thought this was the rationale behind DOD 2167A -- swamp the process with
  28. so many documentation demands that any variability in the actual
  29. production phase becomes a small insignificant blip. :-)
  30.  
  31. Theory of the month:
  32.  
  33. Documentation that no one needs, no one reads, and no one understands
  34. should not be produced.  The radical idea here is that documents of
  35. any form and at any stage should have a existential purpose beyond
  36. meeting contractual obligations.
  37.  
  38. -- 
  39.  
  40. Mike Lutz
  41. Department of Computer Science
  42. Rochester Institute of Technology
  43. Rochester, NY 14623-0887  USA
  44. +1 (716) 475-2472
  45. mjl@cs.rit.edu
  46.