This is actually the whole mistaken premise that underlies the notion of software architecture and design. Building software is not at all like building a bridge or a sky scraper. It's more similar to designing those.
With big architecture projects you first design them and then build them. This is a lot of work. You have to think about everything, run simulations, engage with stakeholders, figure out requirements and other constraints, think about material cost, weight, etc. Months/years can be lost with big construction projects just coming up with the designs. The result is a super detailed blueprint that covers pretty much all aspects of building the thing.
It's a lot like building software, actually. These design projects have a high degree of uncertainty, risk, etc. But it's better than finding out that it's all wrong before you start building and using massive amounts of people, concrete, steel, and other expensive resources. But when have you ever heard an architect talk about making a design for their design to mitigate this? It's not a thing. There might have been a sketch or a napkin drawing at some point at best. SpaceX has introduced some agile elements into their engineering, which is something they learned from software development.
With software, your finished blueprint is executable. The process of coming up with one is manual, the process of building software from the blueprint is typically automated (using compilers and other tools) and so cheap software developers do it all the time (which wasn't always the case). The process of creating that executable blueprint has a lot of risks of course. And there might be some napkin/whiteboard designs here and there. But the notion that you first do a full design and then a full implementation (aka. waterfall) was never a thing that worked in software either. With few exceptions, there generally are no blueprints for your blueprint.
Read the original paper on Waterfall by Royce. It doesn't actually mention waterfalls at all and it vaguely suggests iterating might be a good idea (or at least doing things more than once). He fully got that the first design was probably going to be wrong. Agile just optimized away the low value step of creating designs for your blueprints that becomes apparent when you iterate a lot.
With big architecture projects you first design them and then build them. This is a lot of work. You have to think about everything, run simulations, engage with stakeholders, figure out requirements and other constraints, think about material cost, weight, etc. Months/years can be lost with big construction projects just coming up with the designs. The result is a super detailed blueprint that covers pretty much all aspects of building the thing.
It's a lot like building software, actually. These design projects have a high degree of uncertainty, risk, etc. But it's better than finding out that it's all wrong before you start building and using massive amounts of people, concrete, steel, and other expensive resources. But when have you ever heard an architect talk about making a design for their design to mitigate this? It's not a thing. There might have been a sketch or a napkin drawing at some point at best. SpaceX has introduced some agile elements into their engineering, which is something they learned from software development.
With software, your finished blueprint is executable. The process of coming up with one is manual, the process of building software from the blueprint is typically automated (using compilers and other tools) and so cheap software developers do it all the time (which wasn't always the case). The process of creating that executable blueprint has a lot of risks of course. And there might be some napkin/whiteboard designs here and there. But the notion that you first do a full design and then a full implementation (aka. waterfall) was never a thing that worked in software either. With few exceptions, there generally are no blueprints for your blueprint.
Read the original paper on Waterfall by Royce. It doesn't actually mention waterfalls at all and it vaguely suggests iterating might be a good idea (or at least doing things more than once). He fully got that the first design was probably going to be wrong. Agile just optimized away the low value step of creating designs for your blueprints that becomes apparent when you iterate a lot.