zlacker

[return to "How I estimate work"]
1. thepti+dB[view] [source] 2026-01-24 16:02:55
>>mattjh+(OP)
> This is, of course, false. As every experienced software engineer knows, it is not possible to accurately estimate software projects.

This is a cop-out. Just because you can’t do it, doesn’t mean it’s impossible :)

There are many types of research and prototyping project that are not strongly estimable, even just to p50.

But plenty can be estimated more accurately. If you are building a feature that’s similar to something you built before, then it’s very possible to give accurate estimates to, say, p80 or p90 granularity.

You just need to recognize that there is always some possibility of uncovering a bug or dependency issue or infra problem that delays you, and this uncertainty compounds over longer time horizon.

The author even gestures in this direction:

> sometimes you can accurately estimate software work, when that work is very well-understood and very small in scope. For instance, if I know it takes half an hour to deploy a service

So really what we should take from this is that the author is capable of estimating hours-long tasks reliably. theptip reports being able to reliably estimate weeks-long tasks. And theptip has worked with rare engineers who can somehow, magically, deliver an Eng-year of effort across multiple team members within 10% of budget.

So rather than claim it’s impossible, perhaps a better claim is that it’s a very hard skill, and pretty rare?

(IMO also it requires quite a lot of time investment, and that’s not always valuable, eg startups usually aren’t willing to implement the heavyweight process/rituals required to be accurate.)

◧◩
2. funrep+xE[view] [source] 2026-01-24 16:27:30
>>thepti+dB
Did you read the article? They go on explain how you actually do it, in a very reasonable way.
[go to top]