> Remember that the management culture was one of the hottest topics in the investigation of the Challenger disaster. Perhaps it's a good idea to revisit the findings of that investigation, as well as the venerable and effective Apollo design philosophy.
IIUC, the goal of SpaceX's "Agile" approach to lower the costs of putting payloads into orbit via launch vehicle reuse by amortizing the R&D and equipment cost over multiple profitable launches. They are searching for the cheapest route to achieve large payload space launches.
NASA's goal in the Apollo program was to spend whatever was necessary in order to match and surpass the Soviets' accomplishments. While I don't doubt they were scrappy when necessary, I suspect that the reputational cost of repeated failures (to the country and individuals) was such that it was worth investing time into "getting it right". When fatal failures happened, it was treated as a national disaster and the dead are today considered heroes: https://www.nasa.gov/mission/apollo-1/
Today nobody would even consider risking their lives (nor be asked to) in the way that the Apollo astronauts did, perhaps because the goals (for profit or the mars-fantasy) are considered to be less virtuous.
Perhaps the quality control doesn't need to be as high when you perceive there is less at stake and you can just do it again and again (until the money runs out). That's not to say that this approach won't eventually work, but the motivations and guiding narrative seem to be really different than in the past.
> IIUC, the goal of SpaceX's "Agile" approach to lower the costs of putting payloads into orbit via launch vehicle reuse by amortizing the R&D and equipment cost over multiple profitable launches.
An issue that's deeply intertwined with reusability is reliability. We put absolute emphasis on reliability with expendable launchers. But if you think about it, this is even more paramount in the case of reusable launchers. Hardware tends to degrade overtime, increasing the chance of triggering any design or manufacturing flaws. Expendable launchers need to contend with this only once and for a short time. Reusable launchers have to deal with it over several flights, several structural and thermal cycles (causing fatigue cracks) and a large accumulated operating time. Periodic maintenance can eliminate some flaws - but not design flaws. Launchers also tend to be very sensitive to design flaws, due to the very low engineering margins available. So, there is a bigger incentive here to get it right in the first try itself. (For example, consider the fact there are fewer entities with the capability to build the common turbofan engine than to build a rocket engine.)
Another point is that the agile methodology banks on one particular behavior of software. They rarely degrade over time (unless you manage to leak resources wildly). This makes it amenable to rapid trials, failures and corrections. The cost of experimentation is also minimal, since you don't lose hardware in the process. But in hardware projects, many flaws show up only after an extended period of testing. The trials and corrections are also costly and strenuous.
> They are searching for the cheapest route to achieve their goals.
You may have realized by now what I'm trying to convey. I'm not sure if the agile method is the cheapest route in space tech.
Presumably this was all well understood from history/experience before they applied Agile approaches to space launch. What changed that made this a plausible way to proceed? Some fundamental breakthrough or just Musk's deep pockets?
I don't think anything changed fundamentally. Honestly, the design methodology for any engineering project would evolve organically to be similar to NASA's methodology as its complexity grows. Despite how it looks, Falcon 9 is actually a very conservative design that doesn't depart much from this philosophy. They did everything possible to keep the complexity low and reliability high. Merlin is a simple open cycle engine utilizing pintle injectors. The propellant combination was well known. The vehicle materials and structures were similar to traditional designs. Pneumatic systems were favored in place of pyro systems to improve reusability. Even the vertical landing technology (VTOL) was demonstrated in the 1990s (although Falcon is the first one to land vertically after reentry). The designers were industry veterans utilizing NASA's help. And they took a long time to perfect the basic technologies and had already nailed the basic platform design by the time they started experimenting rapidly with high production rates and landing. Switching to agile mode wasn't a big problem at that stage.
Starship on the other hand, was very unconventional from the word go. Stainless steel structures, methane as fuel, full-flow staged combustion cycle engines with near-limit chamber pressures, cartwheel separation maneuver (which they ultimately abandoned in favor of hot staging, with a lot of ongoing issues), use of sea-level engines in space (on the second stage), the belly-down reentry and the final belly-flop maneuver by the starship, etc. There are more than a dozen things in there that nobody has tried before. It just seems like they have too many things on their plate. Musk's deep pockets did play a big role here. But I'm going to avoid speculating on it.
To start with, Falcon 9 and Starship may share some technologies. But they use different engines, engine cycles, propellants, structural materials and dynamics and even manufacturing processes. SS and Falcon are more dissimilar than any other two launchers I've seen from a single company. There are a lot of design data and procedures that you simply can't carry over from one to the other. The only thing you can realistically carry over is the zealousness with which the design and production quality is enforced. But problems like the repeated failure of the Starship fuel lines raise questions about that zealousness. (In my experience, a traditional space industry facing such issues during the development phase would simply throw out the propellant circuit design and start from scratch, paying more attention to its structural integrity. Frankly, I've seen worse. But that approach is present in the Raptor design. Look how different v1, v2 an v3 are.)
I think everyone here knows that the 'move fast and break things' culture has its roots in the agile development methodology from the silicon valley. Meanwhile, the traditional space development methodology has its roots at NASA. It's even more rigorous than the waterfall methodology used in the software industry, with numerous levels of elaborate reviews for designs, test plans, tests results, integration, schedules, status and even the documentation. From what I understood, the agile methodology is optimized to maximize revenue in a project where the underlying tech stack is reasonably well understood and proven. But it's a poor match for a project where the costs, stakes, complexity, subsystem interdependence, uncertainty in subsystem reliability and lack of engineering margins are all very high. Space launcher is the poster child of such projects. Agile is not even suitable for software projects where you're developing something novel and complex.
The main problem with Agile is the 'let's push to production and see what fails' approach. I'm aware that there are elaborate QA procedures to augment the methodology. But the project is much more tolerant to QA failures. Unlike that, you can't simply leave a flaw in a launcher or its subsystem design and hope to resolve it later. Such flaws are technical debts that will stay hidden for a while and then fail spectacularly on a random day, like the holes in a Swiss cheese. Remember that subsystem interdependence is very high. Failures cascade in ways you couldn't have dreamt of. And the required corrections are elaborate, costly, time consuming and often spanning multiple subsystems. The only reasonable way to manage so much uncertainty is to design meticulously for all foreseeable failures from the start, validating those assumptions at every step of the way (This is why they sometimes throw away faulty designs entirely). And that takes a lot of time and focus. The current approach of 'we will launch in one month to make up for this failure' makes me a bit uncomfortable.
I'm not trying to dismiss SpaceX's approach outright. The biggest aspect of any launcher development is the management of complexity and uncertainty. Perhaps they will find a good way to do that without slowing down. They sure have a lot of smart and hardworking employees. But if I were asked to manage one again, I will choose the NASA style again over the agile style. I'm not smart enough to manage with any other method, the level of uncertainties and complexities I expect from a mid-heavy launcher design, much less something like the Starship. Remember that the management culture was one of the hottest topics in the investigation of the Challenger disaster. Perhaps it's a good idea to revisit the findings of that investigation, as well as the venerable and effective Apollo design philosophy.