NASA and Software Engineering
Wednesday, November 10, 2004
In 1997, it was a very good year (try this sentence to Sinatra's
It was a very good year). It was a good decade for software engineers, software development in general, and the Internet (Al Gore invented it in that decade). It was the go-go 90s and venture money was handed out at 7-11 stores--it wasn't quite like that, but by the way we talk about it now it sure sounds like it was.
Anyway, during that year Fast Company was a hip on-line and glossy paper magazine (they used to throw great roof-top parties; Toronto's club London, anyone?). One article that has stuck with me since then is called
They Write the Right Stuff. It's a great article, which portrays NASA's software engineers to be a regular bunch with regular 9-5 schedules, yet they manage to deliver reliable software and with minimal number of bugs.
How do they do it? They have a strict process for requirements gathering and a heavy process of detail design documentation. These documents are probably more complete than anything we've ever laid hands on.
Two things to note:
1. NASA software is nothing like business software.
2. NASA software doesn't have to make a profit.
What I'm trying to excuse is that writing software to generate profit leads to small side effects: it must be written quickly and cheaply.
Can for-profit businesses (or software shops) adopt a NASA-like engineering process and stay profitable in the long run? I wonder...
Comments:
I used to work at Kennedy Space Center. There was an article in one of the computer magazines about our "state-of-the-art" ethernet network back in the late 90's. It was a running joke because our backbone was a single 10mbit cable at the time. Don't believe everything you read. NASA does a lot of business software and like 80% are failures. They get completed but their intended customers don't use the software. Instead they just go buy something from a vendor
You are correct, NASA isn't in the business of making money, they are in the business of spending it. If you don't spend all your budget, you get less the next year. Their requirements engineering sucked because they would try to do all things for all people. That is why most projects fail in my experience: over-engineering.
:)
I guess repeating the old cliche of "the pasture looks greener on the other side" is in order.
I agree with you, I don't believe everything I read, you are also right to point to the failure rate. We, the public, or outsiders of any corporation are more likely to hear of the products or project that have succeded rather than the one that have failed.
I guess the reality of making business (any type of business) is very different from idealistic and romantic views we have of every profession.
In the end, it's about money: making it, or spending it.