home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / c / 16665 < prev    next >
Encoding:
Text File  |  1992-11-17  |  3.3 KB  |  60 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnews!jbr0
  3. From: jbr0@cbnews.cb.att.com (joseph.a.brownlee)
  4. Subject: Re: Will we keep ignoring this productivity issue?
  5. Organization: AT&T
  6. Date: Tue, 17 Nov 1992 13:24:19 GMT
  7. Message-ID: <1992Nov17.132419.16072@cbnews.cb.att.com>
  8. References: <1992Nov13.062945.425@thunder.mcrcim.mcgill.edu> <1992Nov14.100550@eklektix.com> <1509@gistdev.gist.com>
  9. Sender: joe@cbcosmos.att.com
  10. Lines: 48
  11.  
  12. In article <1509@gistdev.gist.com> flint@gistdev.gist.com (Flint Pellett)
  13. writes:
  14. > rcd@raven.eklektix.com (Dick Dunn) writes:
  15. > > ....  On the
  16. > > other hand, we seem to think we've got enough good programmers that we can
  17. > > afford to spend them cleaning up code of a sort they'd never write in their
  18. > > worst drunken stupors.
  19. >
  20. > > Well, I'm no Van Jacobson, but I've certainly had to spend extended periods
  21. > > working on code of a quality for which I would have flunked my first
  22. > > -semester programming students 15 years ago.
  23. >
  24. > This looks to me like an area that someone ought to devote some study to:
  25. > it would be interesting, at the very least, to get some feel for what
  26. > percentage of their time top programmers spend cleaning up after the
  27. > others, (or in consulting/teaching others) and then formulate some
  28. > methodologies for eliminating THAT problem.  If the top people are
  29. > spending half their time cleaning up junk, you have a potential doubling
  30. > of productivity right there.  [...]
  31.  
  32. I think both Dick and Flint have hit on something here.  I have spent most of
  33. my career cleaning up old messes left by others.  Often this is the type of
  34. task a new person coming in to a job is asked to tackle.  If you are good at
  35. doing it, your reward is going to be to get more bad code thrown at you.  I
  36. just try to remind myself that bad programmers are creating both entertainment
  37. and job security. :-^
  38.  
  39. It seems to me that most of the bad code I've seen was primarily written by
  40. one of two types of people:  either by someone who was completely out of their
  41. element such that they had no clue what they were doing, or by a person who
  42. knows enough to be able to do the right thing but is too sloppy to sweat the
  43. details.  Often, the latter case will be said to be the result of time pressure
  44. (though I must question why creating bad software quickly is such a virtue,
  45. especially when it seems to be so easy to do).
  46.  
  47. I wonder if these are not more management problems than anything else.  In both
  48. cases, the person is set up to fail.  Obviously, it makes more sense to place
  49. people in situations where they can succeed.  We have to keep the clueless
  50. people from creating messes in the first place, and work with the sloppy ones
  51. to get them to clean up their act, and try to convince managers that reasonable
  52. schedules actually save lots of money (they do).  The only other alternative is
  53. to get these people out of the way of the good ones entirely, and I don't think
  54. that is going to happen any time soon.
  55. -- 
  56.    ^      _   Joe Brownlee, Analysts International Corp. @ AT&T Network Systems
  57.   /_\  @ / `  471 E Broad St, Suite 2001, Columbus, Ohio 43215   (614) 860-7461
  58.  /   \ | \_,  E-mail: joe@cbcosmos.att.com   Yes, I speak for my company - NOT!
  59.  "Scotty, we need warp drive in 3 minutes or we're all dead!" --- James T. Kirk
  60.