But chairs are made in large runs, 99% of the work is in the factory. So everyone understands that the work of making a prototype is a different thing to the final product.
A better engineering example needs to be completely one-off, like building a movie set, a stadium, or maybe an airport. These also have endless problems with the requirements changing during design & construction.
You are right, movie sets are a way better analogy. Things on movie sets only work if all people involved adopt nearly military discipline, if you talk to people within the industry they always prepare for the worst and still try to do so on budget.
As somebody who worked as a freelance DOP as well, I think the software world could learn a lot by looking into other areas, especially when it comes to how requirements, changes in said requirements and the impact of these changes on the whole are communicated. IMO one of the most important abilities of an professional regardless of field is to be able to estimate how long something might take and how much work it might be. And this means also beeing able to say how much impact a change in requirements would have on the quality and deadline for the final product.
I know from experience that this estimation is harder in software than in nearly any other field, because problems that look simple on first glance might turn out to be nearly unsolvable, while other problems that look hard might have fairly straightforward solutions — and without putting time into it, it might be hard to tell beforehand.
My problem with that is that it seems to be expected that even a developer without any experience should somehow be able to do this kind of estimation?
I work as a freelancer mostly in film postproduction and there are a lot of times when I have take a wild guess on how long it is going to take. It helps to mentally outline all tasks involved and just take a pessimistic guess on how long each of those will take you. Then just sum them and round up to a full day.
If the topic at hand is really something completely foreign to you, be honest about it and tell them the time in which you will get it done for sure. If they don't agree to it, you wouldn't have made them happy anyways.
However: if you are not just a hobby developer, knowing at least roughly how long things take is key — you have to live from it after all: if you earn 1k for a job that takes you two months you cannot pay your rent. And even if you just do it as a side job, being able to give estimates still helps you to use your time wisely.
I don't think an dev without experience is expected to be able to do that. But a professional who has to live of their profession certainly should, if they want to survive.
A better engineering example needs to be completely one-off, like building a movie set, a stadium, or maybe an airport. These also have endless problems with the requirements changing during design & construction.