I can't speak about SpaceX, but with a number of prior/current NASA contractors it is pretty mundane. The key isn't some awesome framework or "new" technology.

I can't speak about SpaceX, but with a number of prior/current NASA contractors it is pretty mundane. The key isn't some awesome framework or "new" technology. In fact, you'd probably be dumbfounded with the technology restrictions and how little they are using current technology. Overall their success comes from process, methodology and time. In addition, most of the time you are engineering for failure, so when failure happens recovery is possible. You can read about the flight computers aboard the shuttle (and Apollo) and how they handled things with them, there are some really interesting articles about it. In more specific, I'd say 80% of the success comes from fairly rigid processes, including the coding standards and testing methodology. Like with C/C++ standards, you'll find a lot of restrictions on what you can use in the language, how you can use it etc. Here is the JPL's C standards, around flight and embedded type projects (they happen to publish most of their standards) http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf And traditionally there has been significant separation of teams, e.g. System Engineering doing requirements analysis and development, Software Engineers building the software and Testing Engineers writing software and procedures to make sure software hits all the requirements and it doesn't fail. At least from what I know and have experienced you also will not see flight or "critical" software changed and flown (or actively utilized) within any short period of time. As time is a major factor in the testing/simulation regime to make sure things work properly. My guess is that even at SpaceX, critical software components in flight today have been completed and tested for months and months before it hits a real flight. Doesn't mean they may not fly it in a passive mode to see what decisions it would make, but it wouldn't be in control. I am sure non-critical components and ground based software has a slightly less rigid process, but probably still fairly tough.