As far as I can tell this group was essentially the world's last human-powered compiler. Their job was to translate what was effectively high-level code[1] into assembly language.
That's cool and all, but your compiler probably has far lower error rates, definitely has much higher repeatability, runs in seconds instead of... years, and doesn't cost tens of millions of dollars per year.
The idea that we should be imitating them is laughable. Automated compilers were light years ahead even at the time.
Maybe one day we'll see an article about the high-level code was designed. Probably not though.
[1] '"Our requirements are almost pseudo-code," says William R. Pruett, who manages the software project for NASA. "They say, you must do exactly this, do it exactly this way, given this condition and this circumstance."' - they may use words like 'specification' and 'requirements', but generally those terms are indicate documents that tell you what to do, not what to do and how to do it.
This is interesting but I could also write perfect code if I could polish the same process over years and years. In regular business you have to work with unclear requirements and unreasonable deadlines. You simply don't get the time to do a good job.
I write safety critical software. We also have unclear requirements and unreasonable deadlines. Communicating with the relevant stakeholders until the requirements are clear and the deadlines are manageable is a very important part of the process. The main difference to normal software development is that we document everything. Every change to the software needs a new or changed requirement, tests and reviews, all documented. It's not done until C2 coverage is reached and each requirement has a test to verify it. Then we had the software off to other people who do even more tests, on real systems. They also document everything.
I don't do safety critical software myself but I work at a medical device company so I see the teams that work on patient facing products. Their cycles are much longer, management doesn't force new enterprise systems on them, they are very deliberate with changes. It's just a different paradigm. I didn't want to belittle the NASA guys but I just don't see much to learn from there. Their approach has the benefit of high quality with the trade off of slow pace of change.
I agree. You get 90% of the quality for 10% of the cost by writing your requirements down, doing code reviews, and testing your programs thoroughly.
In fact, if quality is your main goal and you don't have to prove process compliance you can probably have a much safer product than the compliant competition by just investing the time spent on documenting every process step on writing better requirements, more tests, and refactoring your code to make testing easier. The last point is especially difficult in an environment where every software change needs a requirement.
>This is interesting but I could also write perfect code if I could polish the same process over years and years.
Could you, though? It's not that they write trivial code just because they have clear specs.
And a simple mistake can make you explode while in space.
Sure, we might have to deal with unclear specs and changing requirements, but even given that most of what we do is 1/1000 to 1/10 the complexity of what NASA programmers do.
I love articles on space programs programming, but this one is so condescending to usual computer project/programmers it's not worth reading. It does not mention enourmous amount of resources put into tiny software to get it perfect. As if in the future all the software will be like that.
Facts are all right, but tone and ideas in this article are horrible.
I do get a little sad every time I listen to a James Taylor song, and hear the way he can make one guitar sound like six. It doesn't stop me from plucking along on my own.
I've never felt that this article is condescending; in fact, I'd go so far as to say it is, at its heart, aspirational. Look at how great we can be.
this was from 20 years ago. I forgive the author's use of stereotypes. There was a lot of really crappy software back then, and I think he was trying to emphasize the differences in quality and methodology.
I worked for that organization from 1996-2005. Nothing earth-shattering:
- Requirements Reviews with Customer, Requirements Analysts, and Testers all sitting around the same table going over them word by word. (e.g. 12 people to review changing an interface by one parameter so that a new value can be displayed in the cockpit.)
- Code reviews with 8 people around the table going over the changes line by line.
- Independent organizations performing unit tests and system tests on the software. Again, with 10 people around the table going over your test results line by line, plot by plot.
Those code reviews are more commonly called inspections or code walkthroughs and are very very uncommon. Everyone wants to cheap out on testing and quality :/
It's process and people and organization. I mean the sense of mission at NASA appears to be pretty high and substantially common. The processes are just normal engineering. Most software these days is not developed with normal engineering processes. I mean a person can go to a Rails Bootcamp for twelve weeks and be hired as a software engineer. In two years they can become a senior software engineer.
In an engineering culture, a person goes to university for five years and gets out, takes a rigorous test and then works as an Engineer in Training for several years. After a few years of formally structured work experience, the person takes another rigorous test and if and only if the person passes that test they actually are allowed to become an engineer. Maybe a decade after that, they'll have a plausible claim to being a senior engineer.
NASA isn't a typical engineering culture. A lot of engineers have masters and doctorate's on top of normal bachelor's level knowledge.
[0] https://hn.algolia.com/?query=They%20Write%20the%20Right%20S...