> A couple of decades back PMs used to look at historical data to guide the estimates for a new project. If a similar coding work took 2 weeks on average in the past, that gives some basis.

Even that doesn’t work because the time taken isn’t just about similarity to other work, it’s about how your new feature interacts with the current state of the codebase which is not the same as when the similar feature was implemented before.

Ultimately, it’s a complexity problem that’s borderline impossible for our feeble human brains to properly understand. And we consistently misunderstand the nature of that complexity

▲

zkmon a day ago | parent [-]

An aircraft engine could be highly complex, but the flight times can be estimated. Complexity is not issue. Reproducibility, and similarity is missing. Every coding work became an adventure into unknown landscape, with no trekking map.

▲

louthy a day ago | parent [-]

And that cavalier attitude to complexity is literally the cause of so many issues with software engineering. An aircraft engine is almost simple compared to a multimillion line codebase.

▲

zkmon a day ago | parent [-]

The attitude with belief that software work cannot be compared with any other work in other domains, is not going to help. There are far more complex projects out there. Complexity is not feature limited to the work artifacts. It could arise from overall context - funding, worker issues, climate, raw material, political factors, technical issues. But still, estimates can't be avoided.

	▲	louthy a day ago \| parent [-]
		> The attitude with belief that software work cannot be compared with any other work in other domains, is not going to help. I didn't say that, at all. But it is an extreme form of abstract complexity which is different to the more tangible and physical complexity that you might have in say a jet engine. That is not to say a jet engine isn't complex, it is and obviously so; but in many ways I think most people don't fully understand the extreme complexity of a medium to large software project because, on the surface, we've apparently captured a lot of it behind reusable libraries and the like. The reality is much more nuanced due to the fact that most software engineering is not following a technique of provably sound composition of components and therefore complexity emerges and is a sum of its parts. That summing of complexity creeps up on a development team and emerges as bugs, security issues, difficulty in planning, and difficulty in maintenance, etc. My singular argument is: reduce complexity, improve predictability. > But still, estimates can't be avoided. I also didn't state that estimates can be avoided. I ran a tech company for 20 years and I needed to be able to tell everyone else in the company when things are likely to be done. That's just a fact of life.