They Write the Right Stuff (1996)
fastcompany.com
They Write the Right Stuff (1996)
1–10 of 20 posts
Re: They Write the Right Stuff (1996)
#2Comes 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...
Re: They Write the Right Stuff (1996)
#3Anyone have any good pointers on the processes they use to get their error rates so low?
Re: They Write the Right Stuff (1996)
#4Anyone have any good pointers on the processes they use to get their error rates so low?
Re: They Write the Right Stuff (1996)
#5This 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.
Re: They Write the Right Stuff (1996)
#6This 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.
Re: They Write the Right Stuff (1996)
#7This 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.
>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.
Re: They Write the Right Stuff (1996)
#8Anyone 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.
- 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.
Re: They Write the Right Stuff (1996)
#9This 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…
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.
Re: They Write the Right Stuff (1996)
#10Earlier quoted context omitted.
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…
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, and refactoring your code to make testing easier. The last point is especially difficult in an environment where every software change needs a requirement.