home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / software / 4253 < prev    next >
Encoding:
Text File  |  1992-11-12  |  3.2 KB  |  63 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!tcsi.com!hermes!miket
  3. From: miket@hermes.tcs.com (Michael Turner nmscore Assoc.)
  4. Subject: Re: Will we keep ignoring this productivity issue?
  5. Message-ID: <1992Nov12.225440.14448@tcsi.com>
  6. Sender: news@tcsi.com
  7. Organization: Teknekron Communications Inc.
  8. References: <1776@aviary.Stars.Reston.Unisys.COM> <1992Nov11.055130@eklektix.com> <1992Nov11.173103.15814@blaze.cs.jhu.edu>
  9. Date: Thu, 12 Nov 1992 22:54:40 GMT
  10. Lines: 51
  11.  
  12. In article <1992Nov11.173103.15814@blaze.cs.jhu.edu> wilson@rhombus.cs.jhu.edu (Dwight Wilson) writes:
  13. >In article <1992Nov11.055130@eklektix.com> rcd@raven.eklektix.com (Dick Dunn) writes:
  14. >
  15. >>>...However, it is a fairly-well-established rule of thumb that
  16. >>>very good programmers can be an order of magnitude or more productive than
  17. >>>the average and do a good job...
  18. >>
  19. >>                            ... "It's more like
  20. >>*two* orders of magnitude!  You get the first order-of-magnitude difference
  21. >>when the code is written.  The second comes during maintenance." ...
  22. >>
  23. >>How *can* we afford to be off pondering complexity metrics, bantering about
  24. >>25% changes, gaping in awe at the occasional arguably-possible factor of
  25. >>2, when there's this sort of fundamental difference that's been staring us
  26. >>in the faces for the past several decades?
  27. >
  28. >Before we try to fix this problem, does anyone have
  29. >analogous numbers for other professions?  I would expect that
  30. >professions demanding high creativity would have a large
  31. >difference between the best practitioners and average ones, and
  32. >an order of magnitude is not particularly surprising.  
  33.  
  34. First let's get our own numbers straight!  From _Controlling Software Projects_,
  35. I remember something like a factor of 4 to 5 (not 10) between AVERAGE and best,
  36. and a factor of 10 between WORST and best.
  37.  
  38. The possibility of two orders of magnitude difference -- one from
  39. initial construction, the second from maintenance -- ignores a common
  40. trade-off: that some of the most prolific construction programmers can
  41. produce almost unmaintainable code.  And the some of the best
  42. programmers from a maintenance point of view code slowly -- maybe even
  43. more slowly than the average, in some cases.
  44.  
  45. Still, I think it's possible to have SOME of the best of both worlds.  If you
  46. think of a new program as one that you are "maintaining into existence" (Cf.
  47. Peter Deutsch's famous comment: "Programming is debugging a blank sheet
  48. of paper"), then you can expect to keep a fairly high rate of productivity
  49. on a sustained basis, because you are investing continuously in future
  50. productivity.  But how many of us have the range of skills, abilities,
  51. knowledge, etc. to be this good all the time?  I try to be this way myself,
  52. but get infected quite often by the attitudes of those around me.
  53.  
  54. There is a big problem with the strategy of "Pick the best programmers
  55. and support them totally" as the best approach to higher productivity.
  56. This is not a new idea -- take a look at _The Mythical Man-Month_ for
  57. a review of the Chief Programmer Team concept.  TECHNICALLY, it's very
  58. hard to refute.  The problem, I think, is not technical but political:
  59. it gives these highly productive programmers too much power!
  60. ---
  61. Michael Turner
  62. miket@tcs.com
  63.