Thank you for taking the time to write a long and detailed response, and thank you for providing relevant links.

I disagree that it’s comparable to writing TSQL, since anyone can train to write perfect TSQL, and the challenge doesn’t really change for each problem. You cannot train to make perfect estimates, and the challenge is different each time.

Flight avionics is an interesting example, and I know I’m cherry picking, but it’s to good of an example to pass up; The Lockheed Martin F-35 program has suffered massive cost overruns, and will probably be something like 10 years late. I’m convinced everyone involved were professionals, still the cost and schedule estimates failed spectacularly.

The goal of a project estimate is to give me information about how much a project will cost. If the actual cost is something else entirely, whatever the root cause, the estimate failed to deliver. There may be some root cause (like we decided to build something completely different than we planned to do) were one could argue that the estimate were technically correct, but it was still useless in providing me with the information I needed. That also means any time spent providing that estimate was essentially waste. Any decision based on that estimate were potentially wrong.

So to me it comes down to this (and I know you don’t agree, and that’s fine): Either the project scope and/or domain are so well known that providing a rough estimate takes next to no time, and if not it will be more or less guessing however deep you dig. Bottom line: Spending any significant part of the project on pre-project estimates is a waste of time and money.

Get a rough indication that the problem is solvable and most likely profitable, and start doing something to prove you’re right. Deliver early and often to validate that you are able to create value, stop if you’re not.