Hacker News Reader

Comment by egeozcan | Hacker News Reader

The only correct estimation is actually doing the work and looking at how long it took.

The closest to that is half-assing the task at hand and multiplying the time it took by ten. For prototype to actual application, you multiply it by a hundred. This also applies for the prototypes of the prototypes (100x for the actual prototype, then 100x of that for the proper implementation), and yes, those exist, but they are usually named "concepts".

For bugs: Half the amount of time needed for the feature that caused that bug. They need a workaround? It will actually take longer - except when the workaround is already available and just needs to be applied. Then it's 90% of the proper solution.

View on HN

> The only correct estimation is actually doing the work and looking at how long it took.

You seem to be missing the point of 'estimation' (as in, it is an approximate prediction, not an accurate measure). Admittedly management also tends to miss this same point, and that fact puts a lot of us on the defensive - but the answer can't be to throw estimation out entirely.

If you ask a civil engineer to estimate the cost and timeline of building a bridge, they'll get you an estimate. It'll likely be within 1-2 orders of magnitude of the actual cost/time, due to a bunch of unknown-unknowns that are hard to factor in (things like: how long the legislature will take to permit the build). But it'll still give you useful data about the differences between building a $million foot bridge, and a $100 billion highway bridge...

Yeah, the general attitude that estimation is impossible, guesswork, or useless is simply not commercially or professionally defensible. Other fields do it all the time without our tools, competencies, supposed specialties, or environmental control.

If one needs more information to articulate the issue at hand, get it. If the estimate is being misrepresented (ideal days vs calendar days), clarify. If methodology is uncertain, do it and iterate and improve it with experience.

Playing coy about how long it takes to build a deck based on a sketch and current availability, while making cute wordplay about how ‘the deck has to be built before one can know what deck there was to build to begin with’…? Whatever, Confucius, it really doesn’t sound like there’s enough deck building experience here, and the obfuscation seems unserious and anxiety related.

> Playing coy about how long it takes to build a deck based on a sketch and current availability, while making cute wordplay about how ‘the deck has to be built before one can know what deck there was to build to begin with’…? Whatever, Confucius, it really doesn’t sound like there’s enough deck building experience here, and the obfuscation seems unserious and anxiety related.

Ouch. Usually the ones writing very aggressive comments filled with attacks on stereotypes are the ones with anxiety problems :) You are fighting with the windmills. I do make estimates, and I'm usually better than many at it. It doesn't mean that the others like my estimates.

Also, you didn't even understand what I'm saying. TL;DR: You need to allocate a considerable amount of time on analyzing the task to make the estimate (around 10% of the time it'd take to solve it). I also take a jab at people injecting workarounds for the sake of keeping it in the estimated time and failing.

I don't think you are contradicting me, but I'm not really sure.

Reply on news.ycombinator.com