From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_05,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c617ae447ca32f2f,start X-Google-Attributes: gid103376,public X-Google-Thread: ff121,3ae3fa74ecb04ab8 X-Google-Attributes: gidff121,public X-Google-ArrivalTime: 2002-03-29 10:56:03 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.earthlink.net!newsfeed2.earthlink.net!newsfeed.earthlink.net!newsfeed0.news.atl.earthlink.net!news.atl.earthlink.net!news.mindspring.net!not-for-mail From: Richard Riehle Newsgroups: comp.software.extreme-programming,comp.lang.ada Subject: Re: Ariane Failure Date: Fri, 29 Mar 2002 10:56:37 -0800 Organization: AdaWorks Software Engineering Message-ID: <3CA4B8E5.72909C9B@adaworks.com> References: Reply-To: richard@adaworks.com NNTP-Posting-Host: 41.b2.46.dc Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 29 Mar 2002 19:00:34 GMT X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en Xref: archiver1.google.com comp.software.extreme-programming:12761 comp.lang.ada:21859 Date: 2002-03-29T19:00:34+00:00 List-Id: rjk wrote: > What is XPers response to this? (I was going to ask a more specific > question, but I thought I'd leave it broad until an interesting question is > found). The problem with Ariane V begins with Systems Engineering management. The decisions about what to do when an exception occurs were wrong, and not tested. Although Design By Contract might have helped, I doubt that Eiffel would have been appropriate because of other issues related to Eiffel. I like Eiffel, but don't consider it appropriate for a project such as Ariane V. The SPARK approach to Design By Contract (they don't call it that, but that is what it is) could have worked well, especially since it was programmed in Ada. By the way, the Ada code worked as it was directed to work, but it was given bad directions. The other problem was one of software reuse. We often tout the value of software reuse, but here is case where it was not working as expected. The software module that failed was originally used in Ariane IV, where it worked fine. Without testing, it was used on Ariane V which had slightly different launch characteristics. A perfect good module from one context was used in another context without considering the full range of issues in that new context. We could draw the analogy of a physician who prescribes a medicine for a patient, knowing that this medicine has worked well for other patients with the same illness. If the physician fails to do a complete medical history, including an evaluation of the other medications being used by that new patient, there is the possibility that contradindicated drug interactions might kill this hapless patient. When we reuse existing modules, in safety-critical software, it is imperative that we both inspect and test for interactions that might kill our software. For embedded real-time software these are often timing issues. Those are hard to detect. As to the contention that XP would have prevented the failue of Ariane V, that is mostly wishful thinking, reminiscent of what is often called "Monday morning quarterbacking." There are some XP practices that might have been useful (features that predate XP by some considerable amount of time), but XP itself would not have saved Ariane V, nor would most of the other suggestions made by the Monday morning Quarterbacks. At present, the French are launching the current version of Ariane quite safely. There are other project failures where XP might have been able to save the project. The one that comes to mind quickly is the Denver airport baggage handling system. I am sure there are others. However, I don't want to be accused of Monday morning quarterbacking. That fact is that building software is hard and it is easy to make engineering errors. Our tools and methods can help us do it right, but neither the languages nor the processes can consistently save us from ourselves. Richard Riehle