Hi,

Sorry for being slightly offtopic, but I'm a bit desperate. :-)

All my guestimates of project duration have been so far ridiculously optimistic
and I usually err by a factor of 4x or worse.

Is there any way out of this? How can I improve my estimates? Is there ANY
book or technique worth learning?

Any help would be greatly appreciated.

Fernando Rodriguez said:

That's pretty good, actually.

If you're writing a program that you've pretty much written before, it's
engineering, and you can probably make a reasonable estimate of how long
it will take. (You might even come in early, because you might be able to
re-use much of the existing code.)

But if you're writing a program that you *haven't* written before, that's
research, and it's impossible to tell how long that research will take.
Nobody asked Crick and Watson how long it would take them to discover the
structure of DNA. (Or at least, if they did, the reply would almost
certainly have been unprintable.)

Double your previous estimate. Iterate until your estimate proves with
hindsight to have been pessimistic. If the problem recurs later on,
re-execute the algorithm.

I know this sounds a bit facile, but I'm afraid that it's how reality
actually works. Any estimate of task duration for a task that nobody has
achieved before will inevitably be wrong except by the most ludicrous of
coincidences. It might be short of reality, or it might be long, but it
won't be *right*. Unfortunately, many managers have yet to understand
this, which is why so much software is late, buggy, short on required
features, and over budget.

One possible way out is functional decomposition. Break the task down into
manageable sub-projects, and estimate each sub-project separately. Add up
all the estimates (including the estimate for the sub-project of gluing
all the sub-projects together, of course), and then add 25%. You'll still
be too optimistic, but maybe by not so great a margin.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Fernando Rodriguez wrote:

The closest experience that I have had that worked was a
project that we created detailed functional blocks for the
project and in early meetings asked everyone involved how
long they thought each of their sections would take.

We kept track of the estimated time from each individual
and used early milestones to calibrate each of the individuals
and adjust our estimate when they would be done. 6 weeks
into a 9 month project our completion estimates were within
3 days of the actual completion.

This is just one data point. For this project it worked

Regards

--
Walter Banks, President
Byte Craft Limited
Tel. (519) 888-6911
http://www.bytecraft.com
walter@bytecraft.com

Fernando Rodriguez <frr149REMOVE_THIS@easyjob.net> writes:


Spencer's Law of Estimates: The cost of any engineering project will
exceed the highest estimate by 25%, even when the estimate takes into
account Spencer's Law of Estimates.

--
dhs spencer@panix.com

Richard Heathfield wrote:
Please tell this to my boss!

:-)

Time estimates are by far the least favorite part of my job. They're
pointless, for all the reasons you give.

Frank

On 4 Jun, 12:10, Richard Heathfield <r...@see.sig.invalid> wrote:
he's not kidding!


what you can do is make successivly more accurate estimates as
the task proceeds.


Manager:
"I got a quote off a plasterer last week and he did the job
for exactly what he estimated. Why can't programmers do that"

Nick:
"Because you didn't ask us to plaster a room"


That does seem to help. And most programs consist of known bits and
unknown bits. Prototyping can reduce the uncertainty in the unknown
bits.
Where it breaks down (in my experience) is not that the estimates you
do are bad its the bits you didn't estimate at all (because you didn't
know
about them) that kill you.


--
Nick Keighley

Fernando Rodriguez wrote:
You could try a software engineering group.

You've got to realise the difference between you knocking something up,
and a team going through the whole process and meeting the quality
criteria. Most people estimate based their own inflated opinion of
themselves, want to show off, assume no unexpected issues, and blame
other factors when things go wrong.

Every team and technology is different.

The only thing I've seen work is to base estimates on the actuals (how
long it actually took) of previous work. Then you need to assess the
size of a piece of work relative to what was done before. If
something's too big to estimate, break it down into chunks of a few days
or so.

In general, estimation errors come from missed tasks, systematic errors
(e.g. underestimation of work rate), design flaws and changes in
requirements.

Defect rates and fix times should also be based on previous projects.
(You do track defects, don't you?) Normally you need to allocate at
least half the time again just on bug fixing.

Don't forget to factor in risks, e.g. likelihood of a certain component
underperforming and needing redesign. You should keep a risk register.

For research, the risk is big, and estimates become meaningless. On the
other hand, for something you've done before, the estimates should be
spot on since you just use the actuals from the previous project. The
moral is that you need to finish the research (and maybe prototype)
before it's possible to estimate. You also need to nail the
requirements, use cases and functionality before you can estimate - as
otherwise you don't even know what you need to deliver.

Remember, estimates are art not science. The only way to get good is
practise. Next, you need to get individuals' velocity factors and start
estimating for other people.

You could also try XPlanner. It might help you with decomposition and
tracking.

Your boss is right to demand good estimates, but should be forgiving
because it's quite a hard skill, and is a team effort not the
responsibility of an individual.

"Fernando Rodriguez" <frr149REMOVE_THIS@easyjob.net> wrote in message
programming effort going into them, and smaller projects.

For smaller projects, normally there is a single algorithm at the heart of
the program, and a lot of frills. For instance for a molecular viewer the
algorithm is the transforms to show spheres in a rotateable 3D view. The
frills are buttons to turn off hydrogens, show bonds, load molecules from
files, and so on.

So thing to do is to identify the core and make sure you have the technical
ability to accomplish it. Then estimate how long that will take.
Then list frills in order of priority, and estimate how long it will take to
add each one. If you are not sure how to implement one and it is not
important, drop it to the end of the list. If you are not sure about one and
it is vital to the project (maybe "frill" is the wrong word, "peripheral
module" is a bit less snappy), that's a problem area and you need to sort it
out before estimating.

The result is a list of features and a timescale, but with some safety built
in. If you can't deliver a 100% functional program by the deadline, probably
you can deliver one that does the central task you want it to and has at
least some extra features present.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

"Fernando Rodriguez" <frr149REMOVE_THIS@easyjob.net> wrote in message
news:a33bd84591278ca944957ac9e70@nntp.aioe.org...
well, all of this is very problematic, however:
I try not to estimate the time, rather the "complexity".

so, I create a rough guess in terms of code size and complexity (say,
somewhere between 25 and 35 kloc). I then take into account my average code
inflation rate, which just happens to be around 100 kloc/year (for the past
few years).

so: 25 kloc is about 3 months, and 35 kloc is 4.5 months, so then one can
infer "probably between around 3 and 4 months".


one can estimate a larger piece of code by mentally decomposing it into
pieces, and trying to estimate the pieces, then adding these complexities
(usually possible because projects tend to consist of pieces we know
already).

of course, this doesn't hold up as well if one is uncertain how the whole
thing will work (for example, because it involves unfammiliar pieces, ...).


another problem is the range of applicability:
it doesn't work so we for short timeframes (say, < 1 month), because them
small-scale chaos comes to dominate (on some days, one does a lot, and on
others, not so much).


likewise, it does not work outside the scale of projects that can be
predicted (on a longer-term effort, one may not be able to imagine all of
the pieces, or they may adjustments to the plan, which will necessarily
throw off their estimates).


so, given the inherent problems of long-term predictive planning (aka, that
it doesn't work so well), I instead choose to plan primarily from the point
of view of "right now".

so, the task is not to form elaborate long range plans, but rather to start
working out details of a general "roadmap" for what one wants to do, with
the primary emphasis being on "what can I do right now?...".

or such...

Nick Keighley wrote:
Great idea. When I'm done with the project I'll tell them how long it took!

:-)

Frank Swarbrick wrote:
Now you've got the idea. When you are half done you can usually
tell them how much longer it all will take within an error of 50%.
If someone later objects to that estimate point out that the
project wasn't half done when you estimated. :-)

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


** Posted from http://www.teranews.com **

4x eh, Id hire you. The accepted error even for experienced engineers is
2-5x the original estimate. 4 means you have some experience, anything less
than 2 is unnatural and should be killed on sight. It's not your job to
pre-adjust by 2-5x, its yoru managers job to post adjust the estimate.
Gauging yoru own performance is much ahrder than gauging someone elses. So
either he isnt doing his job, or doesnt know how, or just doesnt care.

I have a boss like that. He always asks me for estimates then complains
even when my WAG's are within 50%. Recently Ive taken to ludicrously
overestimating (It'll take less than a year for some project that will take
maybe 2 weeks). He gets pissed, but at least he stops asking 'are we there
yet?'


"Fernando Rodriguez" <frr149REMOVE_THIS@easyjob.net> wrote in message
news:a33bd84591278ca944957ac9e70@nntp.aioe.org...

The first 90% of a project will take 90% of the time. The last 10% of the
project will take the other 90% of the time.

W is the amount of work you have left to do.
A is the Approximate percentage of work you have completed
G is the General fudge factor (~3.5 +/- 7).

Multiply W * A * G and you get your wild ass guess. Results for values of A
approaching zero become progressively more likely to succeed in the time
estimated.

Fernando Rodriguez wrote:

That's the industry average.

When a boss asks "give me 500 features, and tell me how much they will
all cost", you can't. This is partly because no boss - no matter how
super-human and deserving of excess compensation they may be - can ever
guess which 500 _exact_ features will turn a profit.

So you can't guess which 300 features to actually work on. Next, you
can't guess how long each one takes, and guessing about all of them
together will cause an incredible amount of noise and variation.

Sure - look up Extreme Programming. When your bosses tells you to do 500
features, tell them:

"Okay. First tell us the 5 most mission-critical important demo features
you need to see in one week."

Implement them in one week, with copious unit testing, and pair
programming.

Deliver them. Ask the boss what's the next 5 features - based on actual
experience with these 5 features.

Repeat. If you find a week occupying 4, or 6, features, adjust your
weekly feature count.

Now the estimate question becomes an actual measurement of the rate - the
Project Velocity - of your team. Measuring is better than estimating.

--
Phlip

On Jun 4, 5:00*am, Fernando Rodriguez <frr149REMOVE_T...@easyjob.net>
wrote:
COCOMO (Constructive Cost Estimate) and COCOMO II are good options.
--
http://www.EventHelix.com/EventStudio
Sequence diagram based embedded systems design tool

"EventHelix.com" wrote:

"Software Cost Estimation with COCOMO II" Barry W. Boehm et al..
Prentice Hall ISBN 0-13-026692-2

QA76.76.C73 S64 2000

This book models development projects and is a very good read
just to understand the issues in managing software projects.

It comes with a CD of tools, videos and spreadsheet models

My opinion money well spent

Regards

--
Walter Banks
Byte Craft Limited
Tel. (519) 888-6911
http://www.bytecraft.com
walter@bytecraft.com

Fernando Rodriguez wrote:

Try some 'iterative refinement' as well. As the project progresses (and
after it's over) compare your prediction to reality & try to understand why
they don't agree. Apply what you learned the next time around.

--
Al Dunstan, Software Engineer
OptiMetrics, Inc.
3115 Professional Drive
Ann Arbor, MI 48104-5131