home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / software / 3351 < prev    next >
Encoding:
Text File  |  1992-09-02  |  1.8 KB  |  41 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!munnari.oz.au!manuel!sserve!ccadfa.cc.adfa.oz.au!ghm
  3. From: ghm@ccadfa.cc.adfa.oz.au (Geoff Miller)
  4. Subject: Re: Software Generation & Maintenance
  5. Message-ID: <1992Sep3.031754.9662@sserve.cc.adfa.oz.au>
  6. Sender: news@sserve.cc.adfa.oz.au
  7. Organization: Australian Defence Force Academy, Canberra, Australia
  8. References: <1992Sep2.084256.1@jaguar.uofs.edu> <16856996F.IQTI400@INDYCMS.IUPUI.EDU>
  9. Date: Thu, 3 Sep 1992 03:17:54 GMT
  10. Lines: 29
  11.  
  12. IQTI400@INDYCMS.IUPUI.EDU (macphil) writes:
  13.  
  14. >Since there seems to be so much time devoted to proper coding methods,
  15. >etc. and there seems to be so much feeling in the industry that it is
  16. >easier to patch and propogate poor code because it is running, how
  17. >about some means to determine when it is more beneficial because of
  18. >newer techniques, languages, tools, methodologies to rewrite the silly thing?
  19.  
  20. I recall reading about a USAAF development project (I _think_ it was
  21. USAAF, and I _think_ it was early 80s) in which the standard for 
  22. rewriting as opposed to fixing a module was:
  23.  
  24.      "If you can't identify the bug in 10 minutes, rewrite the module."
  25.  
  26. Now, (a) this is hazy recollection, and (b) it applied to specific modules
  27. rather than to a whole system.  More generally, we all have to justify to
  28. someone how we spend our time, and if it looks like less time will be 
  29. spent over a reasonable system lifetime by re-writing rather than continuing
  30. to patch, then the re-write is justified.  This is just life-cycle costing
  31. applied to applications development.  What I'd be interested to know
  32. is what people now think a reasonable system lifetime is, given that in
  33. the wonderful open systems world we expect our applications to be 
  34. hardware-independent [:-)/2].
  35.  
  36. Geoff Miller  (g-miller@adfa.oz.au)
  37. Computer Centre, Australian Defence Force Academy
  38.  
  39.  
  40.  
  41.