From: rick@howtek.UUCP (Rick Roy)
Newsgroups: comp.lang.c,comp.software-eng,comp.sys.mac.programmer
Subject: Re: Productivity of a C programmer ?
Date: Thu, 5 Nov 92 12:11:33 EST
Organization: Howtek, Inc.
Reply-To: rick@howtek.UUCP (Rick Roy)
Distribution: world
X-Mailer: uAccess - Macintosh Release: 1.6v1


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.

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 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. Besides the odd
couple of hours for something usual turning into something usual,
there are *lots* of things that come up just a handful of times in
a person's career that take a few days or more and won't happen again
for years (and not at a predictable time). To restate someone(s) else:
who plans for their sicknesses?

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!

Note: if the IEEE disagrees with me on any of this, take their word.

-----------------------------------------------------------------------
Rick Roy                   Magic is a sufficiently advanced technology.
Usenet:                    rick@phunt.MV.com

Disclaimer: My employer's views are orthogonal to these.
Newsgroups: comp.lang.c