Hacker News Reader

Comment by variaga | Hacker News Reader

In my experience, a substantial portion of poor estimates comes from:

1. An initial estimate is made that is fairly accurate.

2. Someone in management says "that's too long, we've got to find a way to bring in that date"

3. The estimate is revised to assume the best case possible execution time in each task, that resources will be available as soon as they are needed, that everything is fully parallelizable.

4. The estimate now magically matches the target date.

5. Actual execution time is close to the original estimate.

People make bad estimates because (other) people don't want good estimates.

View on HN

Early in my career, when I was young and naive, I used to spend an inordinate amount of time coming up with the perfect estimate. I could pretty well get it dead on nearly all the time, at the cost of wasting a stupid amount of time to determine it.

I soon noticed that it only ever lead to "okay, thanks" from whomever made the requested and that was the end of it. So now I just pick a random number. I still get "okay, thanks" and nothing changed.

Nobody really cares. It turns out it is just something people ask when they are uncomfortable with silence, but can't think of anything else to say.

That tracks. Frequently what people learn about estimating is to optimize out steps 1 and 2 and just make the estimate match the need-by date from the beginning.

My favourite joke whenever I tell people I make up estimates is “I’m completely wrong but I’d rather spend 30s and be wrong than 3h and still be just as wrong.”

The managers are just putting that number into a spreadsheet which then gets combined with other spreadsheets and given to an upper level of management which does the same.

When I get asked for estimates I always ask what number would work best for them and then say that. You'd think I'd get a pushback on that approach, but I don't.

I've found in my career so far estimates are very useless but "key dates" can be very useful.

A key date could be an investor demo, marketing launch, actual physical launch if you are in hardware, etc, most importantly something with an audience outside of any of the core team. Find that important date and work backwards from it and find out what is important to finish by then.

This approach has defintiley saved me a lot of sanity compared to arbitrary "estimates" that are destined to be push forever until you run into one of these key dates.

I'm sure that happens a lot. In my experience, people tend to be bad at estimating things.

As a long-time SWE who eventually (also) managed teams: I found estimates particularly difficult. Some SWEs would give very optimistic estimates (and always miss). Others would "sandbag" their estimates, because they didn't want to have to explain why they were late.

I tried really hard to make sure the SWEs on my team didn't get "blamed" if they were late and asked them to generally give aggressive estimates. My rationale was that if you estimated more time than it really took, you would tend to fill up that time no matter what.

It depends what you do with the estimate. If you have to deliver a product/a functionality where X people depends on it to continue. It's best, in the general case, to overestimate a little to not have the X people preparing to work when they can't. If you estimate to schedule the task for the week, it can be more useful to be more aggressive since missing the deadline is less impactful.

For example, there are a lot of task that I depends on which can be completed in one week or three month. I don't care which it will be, I just want to know when it will be done so I can schedule other tasks before.

> Some SWEs would give very optimistic estimates (and always miss).

This seems to be the easiest case. Keep a spreadsheet with two columns: the time they estimated, and the actual time. Calculate the average coefficient between the columns. Next time they give you an estimate, don't comment on that, just privately multiply it by the coefficient.

I've had similar experiences but also reversed - saying estimates are too short, adding a buffer, saying they don't seem valid and we need to account for potential issues.

But also situations where a sales person would throw an estimate to the client which would end up being the official estimate due to no pushback. Or clients stretching the scope of a feature. Or underestimating/lack of understanding of a feature. Or changes from up top in the last days of building a feature.

Or the worst - overestimating due to previous experiences, where the dev team ended up on an 8 month estimate for 3 months worth of work tops which, if true, would have probably sank the company.

They can really be correct or close to truth - and useful to know what an ideal/okay/worst case is for planning, but are often then used as the holy grail and broken due to external influences.

The most useful thing about them is actual ritual of estimating, as it requires the team to mentally go through the items in the spec and align on things they usually would handwave away.

We value optimism, and telling ourselves that something won't be that much work makes it easier to start and commit ourselves to finding out that it's more work than we want later.

Reply on news.ycombinator.com