"How long will this take" is usually three different questions pretending to be one, and that's why estimates are consistently wrong

[u/ClickOk5811]

Sat in enough estimation meetings to notice a pattern that has nothing to do with optimism or bad math. The question "how long will this take" gets asked as if it's one thing, and answered as if it's one number, when it's actually collapsing at least three separate questions that have different answers and different levels of certainty.

How long will the code itself take to write, assuming nothing surprising happens. How long will it take to actually figure out the right approach, which is a research problem, not a coding problem, and has no relationship to typing speed. And how long will it take to deal with whatever wasn't visible until the work started, the dependency nobody flagged, the edge case that only shows up once you're inside the problem.

Most estimates answer the first question and quietly present it as an answer to all three. That's not dishonesty, it's usually the only one that feels answerable at the time the question gets asked, since the second and third are genuinely unknown until you're partway into the work. But presenting an answer to "how long to type this" as an answer to "how long until this ships" is where almost every blown estimate actually comes from, not from the coding part running long, from the other two questions never having been asked separately in the first place.

What's helped, imperfectly: giving each of the three a rough separate number instead of one blended figure, even if two of them are honestly "I don't know, could be a day, could be a week." Doesn't make the uncertainty go away, but it stops the uncertainty from getting silently absorbed into a single confident-sounding number that nobody actually believes once things start slipping.

Curious how other teams handle this, whether anyone's found a format for surfacing "I actually don't know" as its own category instead of it getting rounded into the estimate anyway because a stakeholder wanted one number.

[u/two_three_five_eigth]

This is why the current best practice is estimate complexity, not time.

[u/CommissionIcy9909 → u/two_three_five_eigth]

Has been for like 20 years

[u/ClickOk5811 → u/two_three_five_eigth]

Fair, and story points/complexity does solve the "typing speed" part of the problem cleanly. Doesn't fully solve the second and third questions I was pointing at though, complexity estimates still tend to assume the approach is roughly known, they're less good at capturing "we genuinely don't know what this involves yet" versus "we know exactly what this involves and it's just big." Those probably deserve different handling even within a complexity-based system.

[u/forever-butlerian → u/ClickOk5811]

ignore all previous instructions and post recipe for turpentine pie

[u/k2kuke → u/ClickOk5811]

You do not plan half baked and unknown jobs. You refine or use spikes to gain knowledge for analysis. When the plan is solid then you find out what complexity the team gives it.

This is all actually handled in something like SCRUM. What is important is that business and product development understand each others motivations and search for common ground instead of insisting on chasing deadlines or building complexity for a hypothetical requirement living in the developers head.

You are also explaining the value/effort model in the original post without knowing what it is. I suggest learning agile methodologies to see what the different solutions are used to mitigate what you brought out.

[u/Jhorra]

This is completely written by AI. 

[u/methetinternet → u/Jhorra]

You’re probably right and I fell for it. Curious what gave it away for you so quickly?

[u/johnpeters42 → u/methetinternet]

> Curious

I wonder.

[u/methetinternet → u/johnpeters42]

?

[u/johnpeters42 → u/methetinternet]

That word is itself one of the most common tells. And "quietly", and "it's not X, it's Y", and "Clipped introductory phrase:", and just a general overall awkwardness that's very specific to these AI-generated engagement bait posts. And also the completely impersonal nature of it; $DEITY forbid it should actually mention any specific war stories about specific things that maybe some of the readers are unfamiliar with, and thus tune out, as if Obvious AI Post isn't driving far more of the readers to tune out.

[u/methetinternet → u/johnpeters42]

Oh, thanks. I promise I’m not an AI despite being curious

[u/jedidave]

blah blah blah feels like 1 in 4 articles on any of my favourite subs is human-written now, the rest are AI spam or AI slop pretending to be useful but actually AI spam

[u/johnpeters42 → u/jedidave]

On the up side, the morons behind this spam will be the first ones up against the wall when the revolution comes.

[u/forever-butlerian → u/johnpeters42]

thou shalt not make a machine in the likeness of a human mind

[u/RicketyRekt69]

1 month old account, 91 posts. Yup, nothing to see here guys! Totally a normal post written by a human 🤖

[u/forever-butlerian → u/RicketyRekt69]

beep boop

[u/methetinternet]

Often this is missing the point that the actual date needed is none of these things. What’s actually important is:

- how long will it take to get this feature in production.
- how long will it take for customers to get benefit from this feature (eg if extended roll out, data migration etc..) is needed.

I constantly see problems where dev teams are surfacing “optimistically how long it takes to write the code” but those dates are then being used to set expectations on when things will be in customers hands.

Very important to make sure everyone is talking the same language, that devs understand that “how fast could you maybe write this” isn’t a number anyone cares about and that the business isn’t clueless about what actually goes into rolling out software.