zlacker

There is a counter intuitive thing about software project estimation that took a long time for me to discover.

The more rigorously you try to analyse the problem, cutting it into smaller and smaller parts, the more error you introduce, reducing the value of the estimate at each step.

Thus, the best practice is to give a very rough estimate based on the scale of the project and your past experiences.

If you don't have previous experience with similar projects, then you should not even try to estimate.

>>stephc+(OP)
Well it sounds like you are not doing Agile correctly.

Jokes aside I think accumulation of errors together the fact that time estimations are hard and Parkinson's law is the fatal flaws with Agile.

> Thus, the best practice is to give a very rough estimate based on the scale of the project and your past experiences.

This is my experience too. It is somehow easier to estimate big scopes then many small that sums up to the same scope. Also you get a better feeling of how far you have come when looking at the big scope then when digging down to the details.

>>stephc+(OP)
Theoretically, this should be the exact opposite of the truth. Breaking a big prediction into a whole lot of smaller predictions is the basic intuition behind Fermi estimation and wisdom of crowds. As long as errors are symmetrically distributed and independent of each error, they'll cancel each other in aggregate.

The problem is estimation errors are not symmetrically distributed because engineers chronically underestimate how long something will take, and the problem is exacerbated by management pressure giving them an incentive to estimate even lower.

>>stephc+(OP)
It’s funny you say this because every software project estimate I’ve ever done has basically been to invent lots of small bricks and fiddle the numbers of these so the total matches what seems to be the intuitive size

>>noname+X6
This is why this is counter intuitive.

We're trained to cut big problems in small parts to solve them.

This is more closely related to human psychology than pure logic.

>>noname+X6
They're also not symmetrically distributed because delays are much larger than surprise wins. A win of 50% and a delay of 50% is already non-symmetrical, because the delay will be quite a bit larger, and the real numbers are even worse. A 5x delay on a particular element would be unsurprising, but to estimate something and then have it surprisingly cut to 1/5th the time is something I've only seen a handful of times in my career. "Oh! There's a library in the code that already does exactly this!"

The distribution of delays is pathological, too. It's not normal or poisson or anything nicely amenable to analysis.

>>stephc+(OP)
My formula is usually to listen to the project idea, talk to a few people, take my first feeling how long it could take and then multiply by 5. This usually is pretty accurate.

>>namdna+5i
yup, me too...then double it

>>noname+X6
It’s the breaking down that is challenging, because the breaking down is the work. The correct breakdown is known when the project is completed. Until then, there are only approximate and probably wrong breakdowns.

Ever had a task with 4 seemingly “easy” parts where 3 are easy and it turns out 4 requires a big rewrite because of some hacked put in 8 years ago that are now deeply ingrained assumptions in the code?

Often you are asked to estimate a 10k part project!