- The blue print analogy is used a lot to argue why software engineering isn't real engineering. The reasoning goes like this: you create a blueprint of something like a bridge and you don't start building the bridge until the blue print is done. Then the bridge building process is reasonably predictable and structured because you already solved all the problems. If only software engineering was that predictable. Of course with software, the process of creating the blue print is literally creating the software. The build step tends to be fully automated (compilation). Blue prints for your blue prints used to be a thing when we had waterfall. Creating a blue print for a bridge or a nuclear plant is similarly less predictable. Because that's where you have to do all your problem solving. That's why so many of these hard engineering projects go way over budget.
- SpaceX is using rapid iterations with rocket design. This is real engineering but they are also doing things that come directly from the agile world like not trying to design the entire rocket waterfall style, failing, and then spending another five years fixing the design. Instead they iterate rapidly, go through lots of prototypes and iteratively refine the rocket.
So, it's not that black and white. The process of creating good blueprints on a predictable schedule is not a solved problem. Also not in hard engineering projects. Using agile methodology and testing your blueprints in either simulated or real form helps.
>you create a blueprint of something like a bridge and you don't start building the bridge until the blue print is done. Then the bridge building process is reasonably predictable and structured because you already solved all the problems
Which is hilarious, because nothing in the real world works that way. My BIL is a civil engineer and he spends tons of time traveling to sites to solve problems that pop up during implementation.
- The blue print analogy is used a lot to argue why software engineering isn't real engineering. The reasoning goes like this: you create a blueprint of something like a bridge and you don't start building the bridge until the blue print is done. Then the bridge building process is reasonably predictable and structured because you already solved all the problems. If only software engineering was that predictable. Of course with software, the process of creating the blue print is literally creating the software. The build step tends to be fully automated (compilation). Blue prints for your blue prints used to be a thing when we had waterfall. Creating a blue print for a bridge or a nuclear plant is similarly less predictable. Because that's where you have to do all your problem solving. That's why so many of these hard engineering projects go way over budget.
- SpaceX is using rapid iterations with rocket design. This is real engineering but they are also doing things that come directly from the agile world like not trying to design the entire rocket waterfall style, failing, and then spending another five years fixing the design. Instead they iterate rapidly, go through lots of prototypes and iteratively refine the rocket.
So, it's not that black and white. The process of creating good blueprints on a predictable schedule is not a solved problem. Also not in hard engineering projects. Using agile methodology and testing your blueprints in either simulated or real form helps.