http://www.virtualthought.net/2006/02/05/nasa-coders/ My Clever Tagline™ Tue, 07 Feb 2012 09:15:32 +0000 http://wordpress.org/?v=2.2 http://www.virtualthought.net/2006/02/05/nasa-coders/#comment-267 Virgil Anderson Sat, 25 Feb 2006 15:26:04 +0000 http://www.virtualthought.net/2006/02/05/nasa-coders/#comment-267 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. 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.

]]>