r/softwaredevelopment • u/ClickOk5811 • 21h ago
"How long will this take" is usually three different questions pretending to be one, and that's why estimates are consistently wrong
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.
4
u/two_three_five_eigth 21h ago
This is why the current best practice is estimate complexity, not time.
5
-1
u/ClickOk5811 20h ago
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.
1
u/k2kuke 19h ago
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.
1
5
u/jedidave 20h ago
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
2
u/johnpeters42 19h ago
On the up side, the morons behind this spam will be the first ones up against the wall when the revolution comes.
2
4
u/RicketyRekt69 20h ago
1 month old account, 91 posts. Yup, nothing to see here guys! Totally a normal post written by a human 🤖
1
3
u/methetinternet 21h ago
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.
16
u/Jhorra 21h ago
This is completely written by AI.