All estimations are wrong, but none are useful

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.

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.

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.

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.

This is more or less reverse reasoning starting with a false equivalence. Most construction projects that are a tad different than the typical go over budget and over time. Most construction projects are thesame. If you ask a software engineer to build the same project repetitively, they can give you a very reasonable estimation.

Software development inherently involves more unknowns than fields like construction, making estimation harder. However, when tasks are broken down into simpler, well-defined components with clear requirements, estimation accuracy improves significantly. The challenge lies in the fact that software projects often begin with ambiguous goals, evolving technologies, and dynamic stakeholder needs—factors that are less prevalent in physical construction.

In addition to all of the other comments a good analogy I'd heard in the past is related to plumbing.

If 80% of the way into building a house you realize you want to swap the bathroom and the living room you'd be laughed at. The pipes are laid you and you'd have to drop back down to the 50% complete level to move them.

But this happens all the time in software. It's why so many projects get stuck at the 80/90% level. Because those defining requirements, and many times even engineers, don't have a concrete understanding of what is plumbing and what is finishing it's very difficult to know whether the ask is to hang wallpaper or move a toilet.

Never mind cost/time estimates, most software projects barely have anything resembling blueprints, bill of materials or even size estimates at the start of the project. It's hard to estimate something if you don't even know how big it'll be, or what shape.

No, even construction projects don't get accurately estimated. Software development is R&D, not a construction - lot more unknowns. It is not skill issue by any means.

I think you’re right to a degree. Certainly there is a lazy approach to estimates in software compared to other fields. But I think that’s because the estimation is hard enough to feel hopeless at times. Unless the task is truly something mundane that’s been done 100x before, as in the case of construction where many things are standardized, then the buffer for uncertainty needs to be huge, meaning everything is estimated to take a long time, making the whole process pretty useless.

Even for mundane tasks, I frequently find bugs in libraries, software versions that are incompatible with each other unless I apply just the right combination of upgrades and downgrades. SaaS vendors change their pricing structure or deprecate the APIs I am familiar with. At each step, there’s a little bit of debugging, learning, and creativity in working around problems. Each task is a small piece of art, important or otherwise. And you wouldn’t bother asking a painter how long their landscape will take to finish, would you? It could take a day or it could take months. Timebox it if you want, but that won’t have the same result.

You can save time and make better estimates by never going off the beaten path and by reducing your reliance on 3rd parties, but that only gets you so far and results in boring, homogenous software. Kind of like modern architecture and construction practices, which plenty of people don’t like.

In construction, if all you're doing is building (essentially) the same house, with minor variations, and little risk, you can make very accurate estimates.

In contrast, the construction projects that go over schedule and over budget typically involve a certain degree of novelty where you just can't say, "it typically takes me 5 months to build a house from these plans, so it'll probably take 5 months."

The thing with software is that no one writes the same program over and over again. It's more like the situation where someone is building a unique bridge and it goes over budget.

Hmm.

What about the difference between building a house from a blueprint vs building software from tickets?

IMO the blueprint is a much clearer plan.

EDIT: In fact, I'd argue that the software is more like the blueprint itself than the finished construction project.

It's a play on the phrase "All models are wrong, but some are useful" in reference to statistical models (but often applied more generally to scientific or mental models).

It's a reference to "All models are wrong, but some are useful"

It's a low effort way to make you consider all the necessary steps and possible contingencies for delivering the work. Creating the DB, onboarding to the API, etc., etc.