Writing NASA's software

Via Patrick Steele's blog, a great article on the methodology used to write NASA's software.

What I find really striking is the amount of documentation that gets generated, compared to the amount of code. How do you find your way in 40.000 pages of documentation?
It's not really a surprise that shifting the priorities (putting quality ahead of speed and cost efficiency) improves the quality. Spending more time to design ahead of time and reviewing the code does pay off, especially in a project where the requirements are probably quite stable.
But it's good to know that this process does in fact bring the number of bugs down.

Still, some bugs remain for the testers/simulators to find. This shows that no team of developers is currently able to write bug-free code, even with strict processes and rigorous coding.

It definitely provides food for the thought and surely changes my view of "rocket science" development ;-)

Update: The "Murphy's Law Rules NASA" article (via /.) sheds a quite different light on the kind of integration error that occurs in the complex NASA systems.
Most of the examples are physical integration problems, but some software problems are also mentioned. It seems like cost-cutting is a big factor in letting errors slip through.
It's scary that the same design mistake (error-prone designs with parts that can be mounted incorrectly) that was the source of Murphy's law (originally "Every component than can be installed backward, eventually will be.") continue to be made. Maybe IKEA should send some designers over to the NASA ;-)