From: miket@hermes.tcs.com (Michael Turner nmscore Assoc.)
Subject: Re: Productivity of a C programmer ?
Organization: Teknekron Communications Inc.
Date: Fri, 16 Oct 1992 20:10:47 GMT

In article <1bk5ikINNimg@uwm.edu> markh@csd4.csd.uwm.edu (Mark) writes:
>In article <2060@snap> paj@uk.co.gec-mrc (Paul Johnson) writes:
>>[On project estimation]
>
>In article <qX3DsB2w165w@comtch.spk.wa.us> mhughes@comtch.spk.wa.us (Mark Hughes) writes:
>>  The best thing to do is to ask a programmer to evaluate how long it 
>>will take a team to write your project, and then add 20% or so...
>
>>I have heard one method proposed semi-seriously: ask a new graduate
>>for his estimate, double it, and then switch to the next highest
>>units.  So if the graduate says two months, allow four years.
>
>Well, this one is serious....

[There follows an obviously facetious response.]

DeMarco has a good one about this.  He says to take the estimate
back to the programmer who gave it to you, and ask him the probability
that it will run over.  You'll get a range of values, usually.
THEN ask him the probability that the needed thing will be delivered
EARLIER.  He says you usually get a blank look in answer to the second
question.  The stupidity of this should be obvious.  If you were
sincerely interested in a probable length of time (rather than
the shortest possible time), the programmer would be quite comfortable
with the idea of a 50% chance of early delivery.

To always ask (as I have been, repeatedly) "what's the soonest you
could have it done?" is to ask for disaster.  What's the soonest
you could drive to work?  Would you consider running every red light?

Here's how I have PERSONALLY seen estimation that was reasonably accurate.

First, you just have to have a detailed design.  How do you know you have
a detailed design?  You subject each task required by the design document
to the per-task estimation process outlined below, and if you get a
suspiciously large answer (e.g., two weeks), you haven't gone into 
enough detail.  Send it back for more design work.

Second, once you have a detailed design, ask everybody who's on board
to come up with estimates.   The following rules apply:

	1.  In no case shall estimates be supplied SOONER than 24 hours
	    (or one whole working day) after they have been requested.
	    A team member who tries to should be rebuffed by the manager.
	    A manager who tries to get estimates sooner should be
	    rebuffed (gently!) by the team member.

	2.  In no case shall an estimate be accepted if it hasn't been
	    signed off by another team member with whom the task and
	    estimate has been discussed.  (If there is disagreement,
	    always pick the larger number.)

	3.  In no case shall an estimate be delivered directly to
	    a person who is directly responsible for the outcome of
	    the project.  Always use the most neutral intermediary
	    you can find.  (E-mail doesn't count.)

With all the estimates in, build the schedule.  It's longer than
the customer will accept?  Then dicker over disposable functionality,
but don't cave in on your estimates.  Add more programmers with
great care, assigning them early to tasks that must be completed
late in the schedule.

I realize this process begs some questions.  For example, how do you
estimate design time?  You can't--so don't even try.  AND DON'T PRETEND
TO THE CUSTOMER THAT YOU CAN!  Go in small steps, getting paid as you go.
There are excellent political reasons for being incremental on both
sides at this stage anyway.

Exercise for the alert reader: why should this process work well?
Pay special attention to rules 1-3, above.

Answers (mine, anyway) in future postings.
---
Michael Turner
miket@tcs.com
Newsgroups: comp.lang.c