I think the fundamental misunderstanding is that we aren’t building a product. We are doing research and development. We are figuring out how to build something novel, otherwise the customer could just go out and buy it already. Once we’re done with discovery, the computer builds it. So, the customer is like any other who is paying for research and development. It’s not a blank check, but they should go into it without the expectation that something new will be discovered on some accurate schedule.

This is hubris of the field of software engineering. The no-code market and the existence of tools as old as MS Access prove that there are software projects for which a better analogy is not R&D, but construction.

I do note that construction projects are also not good at estimating, but it's folly to suggest that at some level we are not _manufacturing_ rather than _developing_ a widget.

Construction is a bespoke non-factory manufacturing process. If you extend the metaphor:

Estimating large projects is a big construction projects. Those tend to be large buildings and relatively on schedule. Estimating small projects with small teams is bespoke. And more likely to go off schedule when the plumbers can't time well with the electrical services, i.e, you have a dependency on another teams API or something, similarly to how software struggles in small team open ended scope projects with unknowns. But a tightly scoped single-trade software project won't struggle just like construction.

In end, I agree with you that construction is a decent metaphor. But construction is very far from manufacturing a widget, as it's a bespoke manufacturing process with ample site specific constraints

If we're going to talk about construction as the metaphor, then it's done by the computer (e.g. compilation), and it's so cheap or trivial on many projects that developers will ask the computer to build the software hundreds or thousands a times a day (e.g. via test-driven development). In this metaphor, I think the developer would be more akin to a designer or architect, but where the building in question is at least partially novel. If it's not novel in product, people, process, etc., then the client could just go out and buy or use one that has already been produced. The developer wouldn't be necessary.

> We are figuring out how to build something novel

Is it possible to estimate the duration of a process that has never before occurred (e.g. the construction of something novel) with any expectation of accuracy?

All the successful projects I've participated in could have been managed with this simple sentence: "After some indulging in alcoholic beverages, we have signed a contract for <vaguely specified features> to be shipped on <date out of someone's hat>: please, do your best!" And the outcome would have been even better if we hadn't waisted so much time in preparing detailed estimations and later inventing a justification about why those estimations were not precisely met.