> 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.)

▲

etamponi 4 hours ago | parent | next [-]

> But plenty can be estimated more accurately.

As a person that has never encountered a complex software project that can be accurately estimated, I am being a bit skeptical.

The author did make examples of when estimation is possible: easy projects with a very short time horizons (less than an a couple of days, I'd say).

I'd love to hear some examples of more complex software projects that can be estimated within a reasonable variance.

However, I think it should also be acknowledged that the point of the article seems to be in a different direction: it _doesn't really matter_ that you have a good time estimate, because asking for an estimate is just a somewhat strange way for the management chain to approach you and then tell you how much time you have to deliver.

	▲	theptip 2 hours ago \| parent [-]
		> easy projects with a very short time horizons (less than an a couple of days, I'd say). The example I quoted said hours, not days. But even taking your claim of days as estimable, I have seen much better. An example of weeks-long projects I regularly estimate accurately would be things like “in our Django monolith, add this new field/model, and update the state machine with these new transitions, and update the API, and surface the feature in the UI, including standard e2es and UT coverage”. With a team of 10-15 we regularly hit days-to-weeks estimates with in the ballpark of 90% accuracy. (Ie 1-in-10 slips) An example of year-long projects I have seen waterfall’d successfully are IP protocol implementations where the RFC is clear, base frameworks exist, and the org has engineers with decades of individual experience implementing protocols in the same framework. IOW you have senior-staff or principal engineers on the project. > the point of the article seems to be in a different direction: it _doesn't really matter_ that you have a good time estimate I think the idea that you always start with time and define the work is also myopic. In some dysfunctional orgs I’m sure this is true, but it’s not the whole picture. For the fully-generalized principle at play here, I’m a big believer in the “cost / time / scope” tradeoff triangle. In other words, pick two as your free parameters, and the third is then determined. Sometimes time is the output of a calculation, and resource/scope are the input. Sometimes time can be the input and scope the output. It depends. But the article opens by claiming it’s impossible to estimate time, given a fixed scope and cost(resource) input, which is simply false/over-generalizing.

▲

funrep 4 hours ago | parent | prev [-]

Did you read the article? They go on explain how you actually do it, in a very reasonable way.

	▲	theptip 2 hours ago \| parent [-]
		Hi! “Did you read the article” is generally not in compliance with the HN community guidelines. Please don’t do this.