NASA coders
So I’m reading through this Slashdot troll fest about coding and someone posts this neat article about the shuttle group’s coders at NASA and how their software is zero-defect. Surprisingly, according to the article, the group may produce what is the most expensive-per-line program in the world (420,000 lines with a $35 million dollar budget) with impressive stats like ”...[t]he last 11 versions of this software had a total of 17 errors.” I mean, wow. That’s pretty cool. I really respect the hell out of NASA, gotta admit.
Read the article. This group uses what sounds to me like a waterfall approach: lots of up-front planning, lots of documentation, rigid process… and it’s totally working for them. What does that mean for us agile folks? Are we totally wrong?
Nah. I’m very much a “tools that suit the job” kind of person instead of a “this is the best tool ever” kind of person. But it is interesting to point out when people insist that waterfall doesn’t work. Huh.
February 25th, 2006 at 9:26 am
This is perhaps one of few ways to build really big fault tolerant systems which cannot be allowed to fail; You have to plan for every possible problem. Otherwise the shuttle gets up to about 75 seconds and the vibration causes a momentary disconnect and the computer dies… That is a pretty bad time to have a computer failure (max aerodynamic stress). Large organizations have used this approach for years. Among them Bell Labs, NASA, IBM – they are still around in one form or another. I worked for one outfit which never seemed to use, or comprehend, this approach – a digital phone switch company, is today pretty much a non player in any business. This process is about planning things out in detail, and then doing. That is why systems built using this model are still around, forty years or so and counting. Some of these organizations have systems which have been developed and released forty plus years and are still going. Most organizations at least tried to replace their “structured” systems during the 1990’s with “quick and dirty” systems, but after 150 million bucks down the drain, most thought better of the effort. The digital phone switch organization pretty much decided that if they couldn’t do a design and implementation in six months they would just give up completely. “Waterfall” also masqurades under a host of other names “Structured {Analysis,Design,Programming, etc..} sometimes it is known as Structured Development. If you look at articles from the 1970’s any reference to software methodologies will almost certainly be at least an oblique reference to the same set of ideas. NASA of course was into this in the 1960’s when they were building Apollo. As a developer, coder, project leader, team leader, and senior consultant, this is the way to build software; I have done it both ways, and you should choose the method which suits your situation, but if you want reliable, error free software, this is how you do it. On the otherhand if you see yourself as a flyby night operation, you may not need reliable, dependable, and error free software.