From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.lang.c,comp.software-eng,comp.sys.mac.programmer
Subject: Re: Productivity of a C programmer ?
Date: 9 Nov 92 11:32:56 EST
Distribution: world

In article <D2150040.htfvk3@wildthing.howtek.UUCP>, rick@howtek.UUCP (Rick Roy) writes:
> 
> 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:
> ] In article <1992Oct21.181217.28106@sei.cmu.edu>, bwb@sei.cmu.edu (Bruce Benson) writes:
> ] > In article <D2150040.gja5u5@wildthing.howtek.UUCP> rick@howtek.UUCP (Rick Roy) writes:
> ] >>Programmers (IMO) underestimate because of a variety of reasons:
> ] >>      willingness to please
> ] >>      they never allow time for impossible-to-find bugs that take 3
> ] >>              days to fix but only require changing 1 line of code
> ] >>      they forget that they spend .5-2hrs/day on the internet :-)
> ] >>      they don't account for the hour(s)/wk on status reports/meetings
> ] >>      they don't account for phone time
> ] >>      they don't account for Link time
> ] >>      they don't account for time needed to re-stock Jolt/Cheez-Its
> ] >>      they don't account for 3 days of tweaking the spacing of the
> ] >>              interface items (and for GUI people, one more day to create
> ] >>              the perfect color icon).
> ] >>      they rarely account for time to document & write comments
> ] >
> ] > Seems I recall an article sometime this year in IEEE Transactions on
> ] > Software Engineering that showed (for the projects analyzed) that the
> ] > biggest cause of missed schedules was "nonavailability": i.e., unplanned for
> ] > meetings, demonstrations, etc. the programmer had to attend.  Seems to
> ] > support your examples, except I read it as not necessarily the programmers
> ] > fault, but highly likely that management practices are  a primary cause.
> ] >
> ] 
> ] Whoa-ho!  Management practices?  Aren't these very real events in engineering?
> ] Are we not supposed to status?  If there was one management practice that
> ] failed here, it would be bad planning.  And if any engineer working on a joint
> ] project misses these issues also, it is just as bad engineering on his/her part
> ] as it is a management failure.
> ] 
> ] I would ask the following question: give me the measures of how much time you
> ] spent on each of the above listed activities, so that I can plan for them on
> ] the next project, which then theoretically will a have a much better baseline
> ] with which to estimate the next project.
> ] 
> ] George Kambic
> ] sd
> 
> 	I never expected this to devolve into finger-pointing! Most software
> engineers could improve their estimates (IMHO) by making a sincere
> effort to measure and allocate a (long-term) percentage of their time
> for the unexpected. I can't even guess (with any acceptable degree
> of accuracy) how many hours I've spent in the last year on these things.

WHoa-ho!  Where is this finger-pointing?  If a lot of time is really going into
the *unknown*  category, isn't that a very good thing to know?  If we never
learn this, we are never going to be able to plan.
> 
> On the other hand, while I can say that I've never spent over an hour
> per week on a status report, I can also say that if and when my employer
> decides that I have to begin using Ms Word, I will lose time in the
> transition. 
I am presuming that you cannot say  "OK, and here's what it will cost you"
> I would have no control over this. More importantly, I
> have to attend a status meeting once/week. This is not a bad thing
> but I can't tell my boss how much of my time his meeting is allowed
> to take. Although we usually meet for 45-60 minutes, one time it went
> for just over 3 hours. If I allocated three hours/wk when I plan my
> schedule for programming tasks, he'd hit the roof. 

Sounds like a management problem.  This is not intended to be a cop-out.  If
mgmt won't allow you to schedule accurately, based on historical measurements,
then I agree, you have problems.  I may have been assuming a culture that was
getting ready for change  and improvement.

[...]
> Don't worry, be happy! If a manager's job was easy and everything
> could be made to fit a schedule, anyone could do it and they wouldn't
> make the big bucks!
> 

On the other hand,  if managers didn't have to be juggling this all  the time,
maybe they could be planning for the future, and future products, with half a
snowball's chance in hell of actually making it.

George Kambic
sd