
They Write the Right Stuff (1996) - fawce
https://www.fastcompany.com/28121/they-write-right-stuff
======
metasean
Comes up on a regular basis [0], but definitely worth the read if you haven't
already done so.

[0]
[https://hn.algolia.com/?query=They%20Write%20the%20Right%20S...](https://hn.algolia.com/?query=They%20Write%20the%20Right%20Stuff&sort=byDate&dateRange=all&type=story&storyText=false&prefix&page=0)

------
zb
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.

------
dws
Calculating the cost of a line of shuttle code, adjusting for present dollars,
then comparing that with your own code base can be insightful.

~~~
gydfi
My code also crashes two times out of five.

------
maxxxxx
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.

~~~
adrianN
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.

~~~
maxxxxx
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.

~~~
adrianN
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.

~~~
omouse
Hah, the only thing that most people end up doing is code reviews and much of
those are very relaxed and bare-bones.

~~~
maxxxxx
A real thorough code review is a big deal. It probably takes as much time as
writing it.

------
samat
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.

~~~
dmreedy
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.

------
lallysingh
Anyone have any good pointers on the processes they use to get their error
rates so low?

~~~
ChillyWater
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.

~~~
omouse
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
:/

