6 ms·

They Write the Right Stuff (1996)

31 points by bananacurve 13y ago

Spearchucker 13y ago
"1. The product is only as good as the plan for the product." Right up there with Steven Covey's "Begin with the end in mind". I've witnessed it again and again - when agile developers/hackers/programmers grow up they end up doing design up front. Fail fast and often has it's place, but that place is finite.
andersthue 13y ago
Whenever a customer complains about bugs and the price I let them read this article before discussing it.
alatkins 13y ago
I work in a heavily-regulated safety-critical industry (medical devices) and occasionally re-read this article for inspiration. For anyone wanting to dig a bit deeper, check out the NASA Software Safety Guidebook [http://www.hq.nasa.gov/office/codeq/doctree/871913.pdf http://www.hq.nasa.gov/office/codeq/doctree/871913.pdf]
nawitus 13y ago
>The group writes software this good because that's how good it has to be. No, they write software this good because they have enough time (e.g. money) to write quality software.
- greenyoda 13y ago
  There's probably more to it than that. Most other teams of developers, given the same amount of time and money, could probably not write such complex software with so few bugs in it.
  - nawitus 13y ago
    I agree, having more time / money is not enough, but it's a prerequisite.
litmus 13y ago
The road to hell is paved with good intentions. The context in which the space shuttle program is developed has almost no relation to what most developers face in the software world at large, a fact that the article admits toward the end. Lets see: * 35 million dollar budget a year. * developing software that only has "one job", regardless of how hard that job is. * In other words, no evolving software to meet the demands of an evolving world. Fixed requirements 'forever' (as much as forever can be in software terms). No one at NASA is going "hey, I know we developed this for earth orbit but lets alter the design and try use 90% of the same code to go to the moon as well earth orbit. We'll save time and money." (Unlike SpaceX to some extent) * irreversible decisions. safety critical etc. * Due to lavish budget and safety critical risks, reduced schedule pressure. No one wants to be on the other end of a independent report concluding that long hours resulted in sloppy code that got astronauts killed. The above often even doesn't apply to most relatively expensive (in the millions) non-safety critical military and government software. Watch the Pentagon Wars for a hilarious illustration that comes closer to the reality that software engineers face in those environments. Its a scandal that space shuttle software is being used to push pseudo-scientific process ideology. Its often claimed that SEI developed CMMI process using the space shutte software process as a blueprint. CGI Federal was CMMI Level 5 on paper and QSSI was CMMI Level 3. Meaning that the companies responsible for the most public software scandal in recent US history that is healthcare.gov wasted something like $300 mil at t0 writing the "wrong stuff" while claiming to do it "the right way". Enforcing abstract processes instead of dealing with case-to-case facts reminds me of this quote: "We are all capable of believing things which we know to be untrue, and then, when we are finally proved wrong, impudently twisting the facts so as to show that we were right. Intellectually, it is possible to carry on this process for an indefinite time: the only check on it is that sooner or later a false belief bumps up against solid reality, usually on a battlefield." --George Orwell Contrast all this with Elon Musk's thoughts on Process: "Now I have to tell you something, and I mean this in the best and most inoffensive way possible: I don’t believe in process. In fact, when I interview a potential employee and he or she says that “it’s all about the process,” I see that as a bad sign.The problem is that at a lot of big companies, process becomes a substitute for thinking. You’re encouraged to behave like a little gear in a complex machine. Frankly, it allows you to keep people who aren’t that smart, who aren’t that creative." >when agile developers/hackers/programmers grow up they end up doing design up front. er, what? The agile push came people who were reacting against creating pages of useless design up front documentation that was Dead On Arrival as soon as it was written. People in general become more capable in design up front as their knowledge of the domain grows, but that too depends on context. I'm not sure how valuable design up front would be to even an experienced software engineer who is faced with a project in a programming language he hasn't worked with and a customer domain and platform he doesn't know.... related, SpaceX Lessons Learned: http://lwn.net/Articles/540368/ http://lwn.net/Articles/540368/

31 points by bananacurve 13y ago

"1. The product is only as good as the plan for the product." Right up there with Steven Covey's "Begin with the end in mind". I've witnessed it again and again - when agile developers/hackers/programmers grow up they end up doing design up front. Fail fast and often has it's place, but that place is finite.

andersthue 13y ago

Whenever a customer complains about bugs and the price I let them read this article before discussing it.

alatkins 13y ago

I work in a heavily-regulated safety-critical industry (medical devices) and occasionally re-read this article for inspiration. For anyone wanting to dig a bit deeper, check out the NASA Software Safety Guidebook [http://www.hq.nasa.gov/office/codeq/doctree/871913.pdf http://www.hq.nasa.gov/office/codeq/doctree/871913.pdf]

nawitus 13y ago

>The group writes software this good because that's how good it has to be. No, they write software this good because they have enough time (e.g. money) to write quality software.

greenyoda 13y ago
There's probably more to it than that. Most other teams of developers, given the same amount of time and money, could probably not write such complex software with so few bugs in it.
- nawitus 13y ago
  I agree, having more time / money is not enough, but it's a prerequisite.

litmus 13y ago

The road to hell is paved with good intentions. The context in which the space shuttle program is developed has almost no relation to what most developers face in the software world at large, a fact that the article admits toward the end. Lets see: * 35 million dollar budget a year. * developing software that only has "one job", regardless of how hard that job is. * In other words, no evolving software to meet the demands of an evolving world. Fixed requirements 'forever' (as much as forever can be in software terms). No one at NASA is going "hey, I know we developed this for earth orbit but lets alter the design and try use 90% of the same code to go to the moon as well earth orbit. We'll save time and money." (Unlike SpaceX to some extent) * irreversible decisions. safety critical etc. * Due to lavish budget and safety critical risks, reduced schedule pressure. No one wants to be on the other end of a independent report concluding that long hours resulted in sloppy code that got astronauts killed. The above often even doesn't apply to most relatively expensive (in the millions) non-safety critical military and government software. Watch the Pentagon Wars for a hilarious illustration that comes closer to the reality that software engineers face in those environments. Its a scandal that space shuttle software is being used to push pseudo-scientific process ideology. Its often claimed that SEI developed CMMI process using the space shutte software process as a blueprint. CGI Federal was CMMI Level 5 on paper and QSSI was CMMI Level 3. Meaning that the companies responsible for the most public software scandal in recent US history that is healthcare.gov wasted something like $300 mil at t0 writing the "wrong stuff" while claiming to do it "the right way". Enforcing abstract processes instead of dealing with case-to-case facts reminds me of this quote: "We are all capable of believing things which we know to be untrue, and then, when we are finally proved wrong, impudently twisting the facts so as to show that we were right. Intellectually, it is possible to carry on this process for an indefinite time: the only check on it is that sooner or later a false belief bumps up against solid reality, usually on a battlefield." --George Orwell Contrast all this with Elon Musk's thoughts on Process: "Now I have to tell you something, and I mean this in the best and most inoffensive way possible: I don’t believe in process. In fact, when I interview a potential employee and he or she says that “it’s all about the process,” I see that as a bad sign.The problem is that at a lot of big companies, process becomes a substitute for thinking. You’re encouraged to behave like a little gear in a complex machine. Frankly, it allows you to keep people who aren’t that smart, who aren’t that creative." >when agile developers/hackers/programmers grow up they end up doing design up front. er, what? The agile push came people who were reacting against creating pages of useless design up front documentation that was Dead On Arrival as soon as it was written. People in general become more capable in design up front as their knowledge of the domain grows, but that too depends on context. I'm not sure how valuable design up front would be to even an experienced software engineer who is faced with a project in a programming language he hasn't worked with and a customer domain and platform he doesn't know.... related, SpaceX Lessons Learned: http://lwn.net/Articles/540368/ http://lwn.net/Articles/540368/