Calculating the cost of a line of shuttle code, adjusting for present dollars, then comparing that with your own code base can be insightful.
They Write the Right Stuff (1996)
11–20 of 20 posts
Re: They Write the Right Stuff (1996)
#12Earlier quoted context omitted.
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 hi…
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, a…
Hah, the only thing that most people end up doing is code reviews and much of those are very relaxed and bare-bones.
Re: They Write the Right Stuff (1996)
#13Anyone have any good pointers on the processes they use to get their error rates so low?
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. - Indepe…
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 :/
Re: They Write the Right Stuff (1996)
#14I 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.
Re: They Write the Right Stuff (1996)
#15Earlier quoted context omitted.
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, a…
Hah, the only thing that most people end up doing is code reviews and much of those are very relaxed and bare-bones.
A real thorough code review is a big deal. It probably takes as much time as writing it.
Re: They Write the Right Stuff (1996)
#16I 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.
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.
Re: They Write the Right Stuff (1996)
#17Calculating the cost of a line of shuttle code, adjusting for present dollars, then comparing that with your own code base can be insightful.
My code also crashes two times out of five.
Re: They Write the Right Stuff (1996)
#18Anyone have any good pointers on the processes they use to get their error rates so low?
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.
Re: They Write the Right Stuff (1996)
#19I 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.
Re: They Write the Right Stuff (1996)
#20As 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.