home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / software / 3255 < prev    next >
Encoding:
Text File  |  1992-08-19  |  2.3 KB  |  46 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!ftpbox!mothost!white!rtsg.mot.com!king
  3. From: king@rtsg.mot.com (Steven King, Software Archaeologist)
  4. Subject: Re: What is Software Engineering
  5. Message-ID: <1992Aug19.185601.16876@rtsg.mot.com>
  6. Sender: news@rtsg.mot.com
  7. Nntp-Posting-Host: orchid3
  8. Reply-To: king@rtsg.mot.com
  9. Organization: Motorola Inc., Cellular Infrastructure Group
  10. References: <1992Aug12.065800.14202@sserve.cc.adfa.oz.au> <Bsz991.Knr@cmptrc.lonestar.org> <1992Aug17.013339.27319@sserve.cc.adfa.oz.au>
  11. Date: Wed, 19 Aug 1992 18:56:01 GMT
  12. Lines: 32
  13.  
  14. ghm@ccadfa.cc.adfa.oz.au (Geoff Miller) publicly declared:
  15. >musa@cmptrc.lonestar.org (Jeff Musa) writes:
  16. >>Those that create hack programs, force maintenance programmers
  17. >>to write hack fixes and these (one on top of another) cause more time to 
  18. >>be spent figuring out and rewritting code just to fix or enhance.
  19. >
  20. >In my environment those who create the systems can expect to maintain
  21. >and develop them, usually working directly with the users.  Self-interest
  22. >is a powerful incentive to do it right.
  23.  
  24. Not necessarily.  *IF* the developers believe that doing it right will
  25. save them hassle in the long run, then you're right.  But I've worked
  26. with enough people who have an "Oh, let's just make it work" attitude.
  27. This is regardless of the fact that they'll have to fix or add on to it
  28. a year or two later, after they've forgotten what they've done.
  29.  
  30. Another dis-incentive to do it right is schedules and management
  31. buy-in.  I'm currently embattled to convince the managers of a project
  32. to let us do it right to avoid headaches down the road.  The managers
  33. want to "just make it work" and don't agree that neat code is
  34. significantly easier to maintain in the long run.  Mind you, most of
  35. the managers come from a hardware rather than a software background.
  36.  
  37. I agree totally with Jeff Musa.  Hack development forces hack
  38. maintenance, REGARDLESS of who is developing and who is maintaining, or
  39. of the fact that the same person may be doing both.
  40.  
  41. -- 
  42. -------------------------------------------------------+-----------------------
  43. The amount of work that actually got done during the   |      Steven King
  44. week is inversely proportional to the number of        |   Motorola Cellular
  45. entries in 'timetool'.                                 |   king@rtsg.mot.com
  46.