NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/lang/c/16083

Internet Message Format | 1992-11-07 | 4.5 KB

Xref: sparky comp.lang.c:16083 comp.software-eng:4183 comp.sys.mac.programmer:18082
Path: sparky!uunet!noc.near.net!mv!phunt.MV.COM!howtek.UUCP!rick
From: [e-mail] (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.
Message-ID: <[e-mail]>
Reply-To: [e-mail] (Rick Roy)
Distribution: world
X-Mailer: uAccess - Macintosh Release: 1.6v1
Lines: 71


In article <[e-mail]> (comp.lang.c,comp.software-eng,comp.sys.mac.programmer), [e-mail] (Bonus, Iniquus, Celer - Delegitus Duo) writes:
] In article <[e-mail]>, [e-mail] (Bruce Benson) writes:
] > In article <[e-mail]> [e-mail] (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:                    [e-mail]

Disclaimer: My employer's views are orthogonal to these.