September 05, 2006
Failure AnalysisEd Nisley
Looking back at what went wrong is what failure analysis is all about. And you can bet that government-sponsored programs have lots of experience in this realm.
Ed is an EE, an inactive PE, and author in Poughkeepsie, NY. Contact him at ed.nisley@ieee.org with "Dr Dobbs" in the subject to avoid spam filters.
One of the best software guys I know kept a meticulous error log, recording what he did wrong while designing and coding his programs. He would review the log at the start of a new project and choose less-error-prone techniques that would improve his (already phenomenal) ability to deliver complex code that worked perfectly.
He admitted to some depression at making the same simple mistakes over and over again. Even after eliminating known-bad program structures and using known-good techniques, errors still emerged from nooks and crannies. This troubled him greatly.
Most of us, no matter how devoted we may be to our craft, lack that level of, well, compulsion, but it worked for him. Even if you're not at his level, reviewing your projects to discover what you do worst can pay off, if only by discouraging dumb stunts.
What works for you also works for organizations, although few such reviews make it to the outside world. NASA, however, has done a remarkable job of analyzing its failures in public documents that can help the rest of us improve our techniques.
Here's a look at how things went wrong on several projects, with direct quotes from the NASA reports in italics. You may find the same problems in your own projects, even if you have trouble admitting it and, in fact, the parallels with popular development methodologies seem pretty scary to me.
Discussing this stuff necessarily requires a rather high acronym density. Fortunately, most NASA reports include a comprehensive glossary.
|
 |
|
|||||||||||||||||||||||||||||
|
|
 |
||||
 |
|
|||
 |
||||
 |
|
|||
|
||||
 |
|
|||
|
||||
 |
|
|||
|
||||
 |
|
|||
|
||||
