by goku12 | 2025-06-19 11:04:17+00:00
I see that comments mentioning the 'move fast and break stuff' philosophy are downvoted quickly here. While I don't have any direct knowledge of the Starship design and the SpaceX work culture, I do have years of experience in both the launch vehicle industry as well as the software industry. I feel that the concerns with this approach are dismissed too easily. It's true that SpaceX has been an industry disruptor and a trend setter, especially with the Falcon series launchers. But Falcon and Starship are two fundamentally different vehicles and the success of one doesn't guarantee the success of the other. And there may be good reasons why the Starship is struggling when the Falcon 9 became a success that's unlike any before.

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.