home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / software / 4322 < prev    next >
Encoding:
Text File  |  1992-11-17  |  5.2 KB  |  123 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!think.com!ames!pioneer.arc.nasa.gov!lamaster
  3. From: lamaster@pioneer.arc.nasa.gov (Hugh LaMaster)
  4. Subject: Productivity Data (was Re: Will we keep ignoring this productivity issue?)
  5. Message-ID: <1992Nov16.201453.11367@news.arc.nasa.gov>
  6. Sender: usenet@news.arc.nasa.gov
  7. Organization: NASA Ames Research Center, Moffett Field, CA
  8. References: <Bwtn3H.F2@iat.holonet.net> <1992Nov1.132750.9856@vax.oxford.ac.uk> <1776@aviary.Stars.Reston.Unisys.COM> <1992Nov11.055130@eklektix.com>
  9. Date: Mon, 16 Nov 1992 20:14:53 GMT
  10. Lines: 111
  11.  
  12. In article <1992Nov11.055130@eklektix.com>, rcd@raven.eklektix.com (Dick Dunn) writes:
  13. |> This was in the "productivity of a C programmer" thread, about a week ago.
  14.  
  15. Unfortunately, I don't have a new data point for C programmers.  If you can
  16. stand to consider the ugliness of RPG and JCL, there is a recent article 
  17. in the "Software Engineering Journal" on this subject.
  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 who does a lot of real-time, control-system, etc. programming...just
  25. |> to test his reaction, since he's generally good for a strong opinion.  But
  26. |> his retort came from a direction I hadn't expected: he said "It's more like
  27. |> *two* orders of magnitude!  You get the first order-of-magnitude difference
  28. |> when the code is written.  The second comes during maintenance."  (Cf. also
  29. |> Mark Terribile's comments about changes being made to the best code, because
  30. |> it's the code people can figure out how to change.)
  31. |> 
  32. |> Well, maybe the difference is an order of magnitude, maybe two.  Be very
  33. |> conservative, go below the geometric mean; assume it's only a factor of 20.
  34. |> 
  35. |> *ONLY*???
  36.  
  37.  
  38. The data, in "A software development postmortem summary", are as follows.
  39. The project involved the use of RPG, JCL, screen management, data-file
  40. specifications, etc.  A very different environment than the C environment
  41. referred to in the original posting.
  42.  
  43. Classifying by experience ONLY, the authors found the following:
  44.  
  45. Experience Class         Years of Exp.            LOC/month  Errors/KLOC
  46. ______________________________________________________
  47.  
  48. Inexperienced             0-2                      259        13.6
  49. Moderately Experienced    3-7                      692         8.3
  50. Experienced               8+                      1195         5.3
  51.  
  52.  
  53. Now, when you consider the presumed cost of an error, the 4-5X difference
  54. in productivity is magnified (introduce your favorite method of
  55. dealing with cost of errors here).
  56.  
  57. ***********************
  58.  
  59. Herewith the reference:
  60.  
  61. Formatted:
  62. **********
  63.  
  64. Tsui, F., S. C. Hofmann, and W. J. Goldstrohm, Jr., "A software
  65.      development post-mortem summary," Software Engineering Jour-
  66.      nal, vol. 7, no. 4, pp. 277-284, IEE/BCS, London, July,
  67.      1992.  Comment [Hugh LaMaster, personal comment]:  Project
  68.      was in RPG, JCL, etc.  Experienced programmers were 5 times
  69.      faster than inexperienced programmers with 40% of the er-
  70.      rors.   Inexperienced ( 0-2 yrs.)          259 LOC/month
  71.      13.6 errors/KLOC Moderately experienced (3-7 yrs.)  692
  72.      LOC/month  8.3 errors/KLOC Experienced ( 8+ yrs.)
  73.      1195 LOC/month  5.3 errors/KLOC
  74.  
  75.      Software development requires the integration of many con-
  76.      cepts and activities.  We looked at five key elements: peo-
  77.      ple, functions, schedule, tools and processes.  These five
  78.      elements and their dynamics are discussed in the context of
  79.      a business applications project.  This analysis is performed
  80.      in the spirit of a project post-mortem, as encouraged by
  81.      Abdel-Hamid and Madnick.  It also provides data with which
  82.      other business applications developers can compare.
  83.  
  84.  
  85. Bib:
  86. ****
  87.  
  88. %A F. Tsui
  89. %A S. C. Hofmann
  90. %A W. J. Goldstrohm, Jr.
  91. %T A software development post-mortem summary
  92. %J Software Engineering Journal
  93. %V 7
  94. %N 4
  95. %P 277-284
  96. %I IEE/BCS
  97. %C London
  98. %D July, 1992
  99. %K Recommended, software development, productivity, quality
  100. %O Comment [Hugh LaMaster, personal comment]:
  101. Project was in RPG, JCL, etc.  Experienced programmers were 5 times
  102. faster than inexperienced programmers with 40% of the errors.
  103. Inexperienced ( 0-2 yrs.)          259 LOC/month 13.6 errors/KLOC
  104. Moderately experienced (3-7 yrs.)  692 LOC/month  8.3 errors/KLOC
  105. Experienced ( 8+ yrs.)            1195 LOC/month  5.3 errors/KLOC
  106. %X Software development requires the integration of many
  107. concepts and activities.  We looked at five key elements:
  108. people, functions, schedule, tools and processes.  These
  109. five elements and their dynamics are discussed in the context
  110. of a business applications project.  This analysis is performed
  111. in the spirit of a project post-mortem, as encouraged by
  112. Abdel-Hamid and Madnick.  It also provides data with which other
  113. business applications developers can compare.
  114.  
  115.  
  116.  
  117.  
  118. -- 
  119.   Hugh LaMaster, M/S 233-9,     UUCP:      ames!lamaster
  120.   NASA Ames Research Center     Internet:  lamaster@ames.arc.nasa.gov
  121.   Moffett Field, CA 94035-1000  Or:        lamaster@george.arc.nasa.gov 
  122.   Phone:  415/604-1056                     #include <usenet/std_disclaimer.h> 
  123.