home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / c / 16218 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  4.9 KB
  1. Xref: sparky comp.lang.c:16218 comp.software-eng:4199 comp.sys.mac.programmer:18191
  2. Path: sparky!uunet!pageworks.com!world!eff!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!rpi!gatech!usenet.ins.cwru.edu!icd.ab.com!iccgcc.decnet.ab.com!kambic
  3. From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
  4. Newsgroups: comp.lang.c,comp.software-eng,comp.sys.mac.programmer
  5. Subject: Re: Productivity of a C programmer ?
  6. Message-ID: <1992Nov9.113256.9285@iccgcc.decnet.ab.com>
  7. Date: 9 Nov 92 11:32:56 EST
  8. References: <D2150040.htfvk3@wildthing.howtek.UUCP>
  9. Distribution: world
  10. Lines: 81
  11.  
  12. In article <D2150040.htfvk3@wildthing.howtek.UUCP>, rick@howtek.UUCP (Rick Roy) writes:
  13. > 
  14. > In article <1992Oct22.101744.9147@iccgcc.decnet.ab.com> (comp.lang.c,comp.software-eng,comp.sys.mac.programmer), kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo) writes:
  15. > ] In article <1992Oct21.181217.28106@sei.cmu.edu>, bwb@sei.cmu.edu (Bruce Benson) writes:
  16. > ] > In article <D2150040.gja5u5@wildthing.howtek.UUCP> rick@howtek.UUCP (Rick Roy) writes:
  17. > ] >>Programmers (IMO) underestimate because of a variety of reasons:
  18. > ] >>      willingness to please
  19. > ] >>      they never allow time for impossible-to-find bugs that take 3
  20. > ] >>              days to fix but only require changing 1 line of code
  21. > ] >>      they forget that they spend .5-2hrs/day on the internet :-)
  22. > ] >>      they don't account for the hour(s)/wk on status reports/meetings
  23. > ] >>      they don't account for phone time
  24. > ] >>      they don't account for Link time
  25. > ] >>      they don't account for time needed to re-stock Jolt/Cheez-Its
  26. > ] >>      they don't account for 3 days of tweaking the spacing of the
  27. > ] >>              interface items (and for GUI people, one more day to create
  28. > ] >>              the perfect color icon).
  29. > ] >>      they rarely account for time to document & write comments
  30. > ] >
  31. > ] > Seems I recall an article sometime this year in IEEE Transactions on
  32. > ] > Software Engineering that showed (for the projects analyzed) that the
  33. > ] > biggest cause of missed schedules was "nonavailability": i.e., unplanned for
  34. > ] > meetings, demonstrations, etc. the programmer had to attend.  Seems to
  35. > ] > support your examples, except I read it as not necessarily the programmers
  36. > ] > fault, but highly likely that management practices are  a primary cause.
  37. > ] >
  38. > ] 
  39. > ] Whoa-ho!  Management practices?  Aren't these very real events in engineering?
  40. > ] Are we not supposed to status?  If there was one management practice that
  41. > ] failed here, it would be bad planning.  And if any engineer working on a joint
  42. > ] project misses these issues also, it is just as bad engineering on his/her part
  43. > ] as it is a management failure.
  44. > ] 
  45. > ] I would ask the following question: give me the measures of how much time you
  46. > ] spent on each of the above listed activities, so that I can plan for them on
  47. > ] the next project, which then theoretically will a have a much better baseline
  48. > ] with which to estimate the next project.
  49. > ] 
  50. > ] George Kambic
  51. > ] sd
  52. > 
  53. >     I never expected this to devolve into finger-pointing! Most software
  54. > engineers could improve their estimates (IMHO) by making a sincere
  55. > effort to measure and allocate a (long-term) percentage of their time
  56. > for the unexpected. I can't even guess (with any acceptable degree
  57. > of accuracy) how many hours I've spent in the last year on these things.
  58.  
  59. WHoa-ho!  Where is this finger-pointing?  If a lot of time is really going into
  60. the *unknown*  category, isn't that a very good thing to know?  If we never
  61. learn this, we are never going to be able to plan.
  62. > 
  63. > On the other hand, while I can say that I've never spent over an hour
  64. > per week on a status report, I can also say that if and when my employer
  65. > decides that I have to begin using Ms Word, I will lose time in the
  66. > transition. 
  67. I am presuming that you cannot say  "OK, and here's what it will cost you"
  68. > I would have no control over this. More importantly, I
  69. > have to attend a status meeting once/week. This is not a bad thing
  70. > but I can't tell my boss how much of my time his meeting is allowed
  71. > to take. Although we usually meet for 45-60 minutes, one time it went
  72. > for just over 3 hours. If I allocated three hours/wk when I plan my
  73. > schedule for programming tasks, he'd hit the roof. 
  74.  
  75. Sounds like a management problem.  This is not intended to be a cop-out.  If
  76. mgmt won't allow you to schedule accurately, based on historical measurements,
  77. then I agree, you have problems.  I may have been assuming a culture that was
  78. getting ready for change  and improvement.
  79.  
  80. [...]
  81. > Don't worry, be happy! If a manager's job was easy and everything
  82. > could be made to fit a schedule, anyone could do it and they wouldn't
  83. > make the big bucks!
  84. > 
  85.  
  86. On the other hand,  if managers didn't have to be juggling this all  the time,
  87. maybe they could be planning for the future, and future products, with half a
  88. snowball's chance in hell of actually making it.
  89.  
  90. George Kambic
  91. sd
  92.  
  93.