In software, the general process for developing anything is code, test, fix, repeat. This is easy and cheap, because running a program typically costs an incalculably small amount of money.

In rocket science, it's different. Each launch can cost tens or hundreds of millions of dollars, and scale models often have different flow and performance properties, diminishing their usefulness.

Given these constrains, what is the process by which rocket scientists do iterative development?


migrated from physics.stackexchange.com Apr 5 '18 at 7:04

This question came from our site for active researchers, academics and students of physics.

  • 13
    $\begingroup$ The first step to start a disastrous software development project is to believe that development is easy and cheap. In rocket science ground tests are used before launch. $\endgroup$ – Uwe Apr 5 '18 at 7:47
  • 21
    $\begingroup$ Well, there is this. $\endgroup$ – E.P. Apr 5 '18 at 9:14
  • 11
    $\begingroup$ +1 apparently iterative selection of the optimal SE site works too! $\endgroup$ – uhoh Apr 5 '18 at 9:56
  • 5
    $\begingroup$ "Build one to blow up. You're going to anyways..." :-) $\endgroup$ – Bob Jarvis Apr 5 '18 at 13:50
  • 9
    $\begingroup$ We didn't land on the moon until Apollo 11. Just saying. $\endgroup$ – corsiKa Apr 5 '18 at 18:33

Software development has to be iterative, because it's difficult to impossible to mathematically prove that a given piece of software will work as it's intended.

For physical objects, that's not the case. With modern CAD software you can design parts and be pretty sure the design will work as intended. So a lot of testing can be done before the first part is manufactured.

That said, lots of physical tests are still done in rocket development, especially on the more complex parts.

  • engines (or engine parts) are tested on engine test stands
  • structural parts are subjected to structural tests
  • electronics are subjected to environmental testing (temperature and voltage), electromagnetic compatibility and vibration tests
  • entire stages can be tested on large test stands

Iterative development has been done on rockets, esp. in the early years.

  • The V-2 underwent hundreds of test launches, with many ending in fireballs.
  • the N-1 rocket was tested iteratively. The first stage was so large, building a test stand for it would have delayed the program to a point where the space race would be lost for sure, so the Soviets decided to run a series of test launches instead. With boilerplate articles for the upper stages on the first few test flights, adding flight hardware as the tests progressed. 14 tests were planned. Only 4 were carried out, with the last launch almost making it to a full burn on the first stage.
  • The F-1 engine for the Saturn V first stage had issues with combustion instability. Because the cause of the instability was unknown, lots of test firings were done with different configurations, trying to eliminate the instability.
  • 7
    $\begingroup$ "many ending in fireballs" - ah, what we in IT call a media fault. $\endgroup$ – Whelkaholism Apr 5 '18 at 11:26
  • 5
    $\begingroup$ @ThorbjørnRavnAndersen A rocket may actually be more difficult to simulate, depending on how detailed the simulation is, including the actual inner workings would actually be very challenging. $\endgroup$ – wedstrom Apr 5 '18 at 16:30
  • 16
    $\begingroup$ @ThorbjørnRavnAndersen In theory there's no difference between theory and practice. In practice, there is. $\endgroup$ – corsiKa Apr 5 '18 at 18:34
  • 3
    $\begingroup$ "Because it's difficult to impossible to mathematically prove that a given piece of software will work as it's intended" -- I disagree; it's far easier to prove correctness of software than of hardware operating in the real world. It's simply easier still to iterate. $\endgroup$ – Russell Borogove Apr 6 '18 at 0:35
  • 2
    $\begingroup$ Semantics of "proof" and "correct" aside, surely whether it is easy or difficult to prove correctness of software depends entirely on the application domain and complexity; verifying that a simple mathematical function behaves correctly is not difficult, but proving that some sort of image recognition algorithm or a geo-distributed data storage solution is correct might be impossible. Software takes lots of forms. $\endgroup$ – Electric Head Apr 6 '18 at 11:24

Firstly, "rocket science" is a bit of a misleading term. Rockets are a type of propulsion system performing a function within larger systems such as launch vehicles, spacecraft, missile systems, etc. Engineering these complex systems is a holistic, multidisciplinary process. There's an entire discipline dedicated to this type of engineering originating from the 1930s: Systems Engineering.

Systems Engineering and modern software development practices are similar, despite their somewhat independent evolution. Design process models familiar to the IT and software engineering world such as Waterfall and Vee have played their roles, and approaches like Concurrent Engineering have more than a bit in common with Agile software development practices and are intensively iterative. See ESA's description of Concurrent Engineering as an example.

The specific nature of iteration over a system's life cycle is going to depend on the project, who's doing it, who's paying for it and what the life cycle stage is, but the "design, test, fix" paradigm isn't really much different (though, as implied, the scale might be).

Mathematical models, simulation and design patterns are important in keeping costs down, particularly in early design phases. Components and subsystems can be developed and verified against specification, with integration being tested through ground tests as covered in other answers. In some regards it could be argued the physical nature of components makes it easier to quantify and verify against specification than the abstract nature of software [systems] but -- as pointed out -- there are additional difficulties and costs associated with engineering in the physical domain.

Software engineering is a comparatively young discipline and there is a significant degree of convergence occurring as it matures (and software systems get more complex), but engineering is engineering.

Suggestions for further reading:

  • 3
    $\begingroup$ I'd recommend Kelly's Moon Lander instead of the SEBoK. That has Tom Kelly describing how he ran the Grumman program to develop the Apollo LEM at the dawn of modern SE, and is a great read. For more depth, I would go to Morris' The Management of Projects, which covers PM more than SE, but starts from before there was a distinction. $\endgroup$ – fectin Apr 6 '18 at 3:30
  • 2
    $\begingroup$ Thank you; suggestions gratefully received! I took the liberty of adding them. I mentioned SEBoK and SWEBoK because they are resources that naturally illustrate the similarity/convergence, not because they are particularly engrossing reads... :) $\endgroup$ – Electric Head Apr 6 '18 at 9:25

The majority of the components of a rocket can be tested individually on the ground here's an example of a test for the RS-25 engine for the SLS for example. So the majority of the iterative development is done using tests like this.

Obviously there are somethings you only find out when you test the complete stack through a launch of course but extensive ground testing keeps that to a reasonable minimum.

  • $\begingroup$ The engines for a second stage may be tested on ground. But it is difficult to test a powerful rocket engine in a vacuum test chamber. There was a problem of breaking fuel lines in the second stage of Saturn V found in Apollo 6. The problem did not show in ground test with the engine working in the atmosphere. $\endgroup$ – Uwe Apr 9 '18 at 7:32

The short answer is that the iteration happens mostly via analysis (the industry terms of art are DAC and VAC, for Design Analysis Cycle and Verification Analysis Cycle), supported by small-scale development testing where necessary (think unit tests), culminating in a series of qualification tests (i.e., integration tests) near the end of a development project.


The avionics/software on a rocket (one of the bits most prone to failing) can, in fact, be tested iteratively like software. SpaceX has a all the wiring/computers of their Falcon 9 laid out in their factory. They then give these components phony inputs and see how the code responds. These type of simulations are very useful for testing new innovations (like re-usable rockets).

Many, if not most, problems with rockets and spaceships have been related to software. A mars rover crashes because somebody forgot to convert feet to meters, and an Ariana rocket blew up because it went so fast that the speed value had an integer overflow, causing the rocket to think it was traveling backwards (the same kind of bug that gave us Nuclear Gandhi in Civilization).

I know the question was mostly about the physical stuff, which is usually tested in test-stands like Hobbes said in his answer. Still, just remember that modern rockets are just as much software as hardware.

  • $\begingroup$ Interestingly, it's worth pointing out that these software problems can in turn be significantly attributable to communication issues between teams and inadequate processes. $\endgroup$ – Electric Head Apr 6 '18 at 12:05
  • 1
    $\begingroup$ Some relevant keywords: software-in-loop and hardware-in-loop testing. Of course there are also the extensive Continuous Integration suites which are now a critical part of software development in all fields. $\endgroup$ – craq Apr 6 '18 at 20:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.