home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / c / 16602 < prev    next >
Encoding:
Internet Message Format  |  1992-11-24  |  4.1 KB
  1. Xref: sparky comp.lang.c:16602 comp.software-eng:4318 alt.folklore.computers:16296
  2. Newsgroups: comp.lang.c,comp.software-eng,alt.folklore.computers
  3. Path: sparky!uunet!snorkelwacker.mit.edu!bloom-picayune.mit.edu!news
  4. From: scs@adam.mit.edu (Steve Summit)
  5. Subject: Re: Will we keep ignoring this productivity issue?
  6. Message-ID: <1992Nov16.160026.7548@athena.mit.edu>
  7. Sender: news@athena.mit.edu (News system)
  8. Nntp-Posting-Host: adam.mit.edu
  9. Organization: none, at the moment
  10. References: <1992Nov1.132750.9856@vax.oxford.ac.uk> <1776@aviary.Stars.Reston.Unisys.COM> <1992Nov11.055130@eklektix.com>
  11. Date: Mon, 16 Nov 1992 16:00:26 GMT
  12. Lines: 76
  13.  
  14. In article <1992Nov11.055130@eklektix.com>, rcd@raven.eklektix.com (Dick Dunn) writes:
  15. > This was in the "productivity of a C programmer" thread, about a week ago.
  16. > I haven't seen anyone picking up on it... Bob Munck (munck@stars.reston.
  17. > unisys.com) wrote:
  18. > 
  19. >> ...However, it is a fairly-well-established rule of thumb that
  20. >> very good programmers can be an order of magnitude or more productive than
  21. >> the average and do a good job...
  22. > 
  23. > We toss this number around a lot.  A couple years ago I tossed it at a
  24. > friend...  But
  25. > his retort came from a direction I hadn't expected: he said "It's more like
  26. > *two* orders of magnitude!
  27.  
  28. Actually, I had been tempted to comment on Bob Munch's earlier
  29. remark, to point out that the infamous Jargon File (a.k.a. The
  30. New Hacker's Dictionary), for what it's worth, has this to say
  31. about productivity:
  32.  
  33.     ...Productivity can vary from one programmer to another
  34.     by three orders of magnitude.  For example, one
  35.     programmer might be able to write an average of 3 lines
  36.     of working code in one day, while another, with the
  37.     proper tools, might be able to write 3,000.  This range
  38.     is astonishing; it is matched in very few other areas of
  39.     human endeavor.
  40.  
  41. This note appears in the entry on "superprogrammer," a term which
  42. the File notes "is more commonly used within such places as IBM
  43. than in the hacker community."
  44.  
  45. You might reasonably suspect that the several appearances of the
  46. term "hacker" in such close proximity to the above-quoted
  47. statement dilute the credibility of its three-orders-of-magnitude
  48. claim, or relegate such code to the undocumented & unmaintainable &
  49. hence worthless category.  The File's discussion on productivity
  50. continues, however, with the observation that
  51.  
  52.     [Such terms tend] to stress naive measures of
  53.     productivity and to underweight creativity, ingenuity,
  54.     and getting the job *done* -- and to sidestep the
  55.     question of whether the 3,000 lines of code do more or
  56.     less useful work than three lines that do the {Right
  57.     Thing}.
  58.  
  59. It doesn't really matter whether you believe that the factor is
  60. 20 or 100 or 1000; the point is that the factor is definitely
  61. large.  And the suggestion that apples and oranges are being
  62. compared -- that the prodigy can code thousands of <choose your
  63. metric> per day only for certain kinds of projects or only by
  64. neglecting all documentation or only by being antisocial and not
  65. interacting with others -- is sort of dodging the issue: perhaps
  66. it's worth contemplating for a moment the qualities of programs
  67. and the methodologies which do permit such productivity, and
  68. trying to recast recalcitrant projects in more favorable terms.
  69. I love it when some intractable programming task (ugly, grisly,
  70. special-cased grunge code that's impossible and no fun to write
  71. and is guaranteed to have lots of nasty bugs) can, by means of
  72. some change in methodology or avenue of attack or mere outlook,
  73. be transformed into blissfully clean code that practically writes
  74. itself.
  75.  
  76. I agree completely with Dick that it would be valuable to better
  77. understand the factors (whatever they are; internal or external
  78. or otherwise) which allow some programmers to be so much more
  79. productive than others.  That there is a productivity
  80. differential is not unique to programming, but the reasons behind
  81. the differential are more likely to be.
  82.  
  83. I've neglected to honor Dick's Followup-To and have added a third
  84. crosspost; please redirect followups appropriately (software
  85. engineering to comp.software-eng, Jargon File to
  86. alt.folklore.computers).
  87.  
  88.                     Steve Summit
  89.                     scs@adam.mit.edu
  90.