home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / c / 16458 < prev    next >
Encoding:
Internet Message Format  |  1992-11-13  |  4.2 KB
  1. Xref: sparky comp.lang.c:16458 comp.software-eng:4266
  2. Path: sparky!uunet!crdgw1!rdsunx.crd.ge.com!sunroof!hammondr
  3. From: hammondr@sunroof.crd.ge.com (Richard A Hammond)
  4. Newsgroups: comp.lang.c,comp.software-eng
  5. Subject: Re: Will we keep ignoring this productivity issue?
  6. Message-ID: <1992Nov13.143529.9055@crd.ge.com>
  7. Date: 13 Nov 92 14:35:29 GMT
  8. References: <1992Nov11.055130@eklektix.com> <BxMuBK.ArM@inews.Intel.COM>
  9. Sender: usenet@crd.ge.com (Required for NNTP)
  10. Organization: GE Corp. Research & Development, Schenectady, NY
  11. Lines: 66
  12. Nntp-Posting-Host: sunroof.crd.ge.com
  13.  
  14. In article <BxMuBK.ArM@inews.Intel.COM> nsridharan@faois.intel.com (Sridharan) writes:
  15. >In article <BxKEv9.4K8@cs.uiuc.edu> Rob Hasker, hasker@cs.uiuc.edu writes:
  16. >>On what sorts of projects?  While there might be a difference for small
  17. >>projects, it certainly wouldn't be clear that there would be a
  18. >>difference for large projects.  ...
  19.  
  20. >Ahem ... the project wouldn't BE BIG if you used the "very good" people, would
  21. >it?
  22.  
  23. >Try a hypothesis:  What if .. just what if .. the famous 80-20 rules works.
  24. >Examples: 80 percent of the function comes from 20 percent of the code
  25. >    80 percent of the value comes from 20 percent of the effort
  26. >    80 percent of the result comes from 20 percent of the people (in a large
  27. >project)
  28. >    and etc etc
  29. >So, if an ordinary programmer is a slave to the ordinary world
  30. >and if a talented programmer understands how to apply the 80-20 rule and can
  31. >get 80% of the most valuable work done in 20% of the effort; and  
  32. >if a "gifted" programmer is one who can apply the 80-20 rule twice over - and
  33. >can get 64% of the value with only 4% of the effort
  34. >- Would this account for the variability in productivity?
  35.  
  36. >Since the argument is generic - you might say why then don't we see the same
  37. >in carpentry or shoe repair.  Aye, then , the subject matter is not so ELASTIC
  38. >and one cannot effectively do much in that subject.
  39.  
  40. NO!!  The reason we don't see that in shoe repair and carpentry is that nobody
  41. wants an 80% finished job and the fact that it is 80% finished is obvious by
  42. inspection, even to the untrained eye.
  43.  
  44. The problem in software is that we, more specifically management and sales,
  45. can't easily tell the difference between 80% done and finished.  I know that
  46. my code has stubs for all the error recovery, for example, but it appears to
  47. function just fine in a demo, because I avoid the operations which cause
  48. errors.  So, I was very productive the first 20% of the project.  The demo
  49. looks great, but there's a lot of work in getting the regression testing
  50. set up, filling in the error handling, documenting the internals, ...
  51.  
  52. For example, I'm working on a project which is building a multi-processor
  53. in a VME rack.  I'm attempting to add support for a new type of board.
  54. The existing system has two modes that a board operates in, master & slave.
  55. The effort to get the new board up as a slave was maybe 20% of the work.
  56. The problem is that my own system has only the new boards, so one has to
  57. function as a master.  That's taking much longer, there are significant
  58. assumptions about the architecture of the hardware built into the code and
  59. the new boards no longer fit those assumptions.  Besides the hardware, the
  60. problem is that the whiz kid coder, who got the job "80%" done, didn't
  61. comment the code well and spread the functionality and dependencies over
  62. a number of modules, as well as depending on magic constants embedded in
  63. battery backed up RAM, specific versions of ROMS, ...
  64.  
  65. As someone else already pointed out, on a really large project the actual
  66. coding is a small fraction of the total effort.  Most of the effort is the
  67. documentation, design, integration and testing.  The speed of the coders
  68. would make very little difference, and if the code was not easily maintained
  69. then integration & test might take more time than was saved in coding.
  70.  
  71. Most of the fast coders I've seen have been the ones who neglect the non-code
  72. aspects, i.e., design, testing, documentation.  That's fine for small demo
  73. projects but not for large or long lived projects.
  74.  
  75. I think the 10x or more performance difference is a myth from not measuring
  76. all the relevant issues, because it is so difficult to look at software and
  77. say you've only done 80% of the job or 64%.
  78.  
  79. Rich Hammond
  80.