[wtetzner]

> Good estimates are critical to plan dependent activities and setting customer expectations.

One of the things I dislike when I hear this is that it says nothing about the difficulty or cost of getting the estimates. Yes, good estimates are extremely valuable, but solving the halting problem would also be very valuable. That doesn't mean it's going to happen.

A big issue is that to get good estimates, often we need to solve most of the hard parts of the problem. How do we account for the time needed to get the estimates?

> If we don’t estimate then we are saying that software engineering is not an engineering discipline.

I'm not sure I believe this. There are plenty of non-software engineering projects that are late and go over budget. It wouldn't surprise me if that was the norm. Certainly with construction projects it happens all the time.

I'm actually curious about which engineering disciplines actually come up with good estimates. When developing a new type of airplane, or a new engine, are estimates typically accurate? It seems unlikely to me.

[pyrale]

> but solving the halting problem would also be very valuable.

The halting problem is mostly a non-problem in settings that really need a proof. We have non-turing-complete languages that let us produce programs that provably halt.

That they are not mainstream tends to show that we don't really need that proof very often actually.