How NASA writes 'perfect' software (1996)

The thing is that software's taken at a very different angle from there as in most parts.

First, the ones who know exactly what's supposed to happen aren't software people, they're engineers who don't write code. At least not real-time embedded control code.

Second, there are too many different people who's interests come together in the same codebase. I.E. lots of different engineering disciplines at once. Each one has their own work to do separate from the programming. You can get specifications & equations out of them, but the code's a different group.

Third, the need for high assurance is important. Note the word 'Assurance.' If something bad happens at Nasa, there's a lot of news and possibly a statement by The President. Being that this is a government agency building stuff, it's going to have similar problems to DoD agencies building stuff. That is, an incredible amount of the project will be spent to reduce the variability of the project. Even if the sum cost is many [, many]* times the likely variance.

The main space they have to work with is in mechanized assurance systems. Sadly, the formal systems out there aren't terribly evolved, as most people just test & debug their systems to get it right.

As for contributions to software, or lessons learned, there are some very good experiences & things learned for people who want to build better tools to make this stuff easier. E.g. higher-level languages that look more like Matlab than embedded C (don't get me started on Matlab-C converter). Stuff where you can be sure that no matter what instruction sequences you give to a robotic arm, that it never ends up in a position where one of joints is locked.

When I was there, the attempt was natural language to CSP traces, to be run through a theorem prover there later. We had a total of two grad students working on it over a summer, after an initial prototype was written earlier.

As other posts on HN have mentioned, and as one can surmise from the chatter about Nasa, it's costs are very closely looked at by a lot of people -- many who don't understand/know/care about the specific problems Nasa's got. That creates a whole new set of problems. Being observed under a microscope and then being hit for everything a nontechnical senator can get political points for hitting you for will make you start working in pretty strange ways.

You can't show a program to bug free. You can't prove a negative.

"the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors."

Translation: in each of the last three versions, only one error was found, in the last 11 versions, only 17 errors were found.

"the shuttle group now finds 85% of its errors before formal testing begins, and 99.9% before the program is delivered"

In order to know you've found x% of the errors in a program, don't you have to have already found 100% of them? If I find 9 errors in a program, how can I know that I've found 90% of the errors unless I also know that there are 10 errors in it?

A lot of what the author says sounds impressive, but I'd argue a lot of it is either wrong or not even wrong (http://en.wikipedia.org/wiki/Not_even_wrong). Even granting the author some artistic license, he's going pretty overboard in a lot of his claims.

I'm sure the software produced by this group is less error-prone than your typical desktop or web app, but it doesn't sound like they're writing innovative software either. Most of what they do sounds like either mathematical calculations or driving hardware devices. Both areas which seem to me to be pretty well explored at this stage.

It most definitively does not have only one bug in it per release.

However, and this is a pretty key concept: we don't bill them half a billion a year for it. (Not everybody, after all, has access to a virtually unlimited slush fund whose primary purpose is to line the pockets of defense contractors in a PR-friendly way.)

I'll give him his clever phrase, despite being technically false. What we create with our knowledge of computer science (our programming) is not the same thing as computer science itself.

This is an interesting way to think about programming, though. Compare it, for instance, to metalworking. The craft itself, clearly, is distinct from the science of metallurgy, but at the same time they have evolved alongside each other. I wonder if programming and computer science will go through a similar progression. As metalworkers just were learning to manipulate metal, we bit-twiddled and hand-assembled; as metalworkers evolved their tools and meticulously forged their creations, we created compilers but still hand-coded our programs. The next big step in metalworking was the automation of their craft via factories; is this way code will go as well? Will we simply guide computers as they produce their own code? And what advances in computer science would be necessary for this to happen?

Edit: Please forgive me if my history of metalworking is slightly incorrect, I just realized I mostly pulled it out of my ass.

After a day or so, he turned in his code (something like 30 lines) and was chastised for having done too much. "What are you trying to kill people?!?"

Turns out the regular output of their developers was something like 5-10 lines of code per day, and only certain days of the week. Finished products were peer reviewed before being QAd.

At the time, I was just learning early Ruby, and getting used to the concepts of rapid development, and it seemed so strange. Of course, if my webapp breaks, there aren't any lives on the line.

pg: "It's natural for organizations to learn from mistakes. The problem is, people who propose new checks almost never consider that the check itself has a cost."

FTA: "The process is so pervasive, it gets the blame for any error -- if there is a flaw in the software, there must be something wrong with the way its being written, something that can be corrected. [...] Does a question need to be added to a checklist?"

This seems to apply to many areas of life. Create an environment in which failure is simply not an option and no one will choose that option.

Modern AAA computer games have at least double the code size, are produced in a fifth of the time, for the price of roughly 1 year of the NASA group's budget.

This is why we need NewSpace. It would actually be better to fail more often and more cheaply.

Of course, that's impossible for a Congressionally-funded organization.