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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public From: Bertrand Meyer Subject: Re: The stupidity of all the Ariane 5 analysts. Date: 1997/07/20 Message-ID: <33D2827B.41C67EA6@eiffel.com>#1/1 X-Deja-AN: 257881439 References: <33C835A5.362A@flash.net> <33CC0548.4099@flash.net> <5qitoi$fdv$1@news.irisa.fr> <33CD6512.2404@flash.net> <01bc92e6$7a6f9e40$287b7b7a@tlo2> <33CEAF05.6389@flash.net> Organization: Interactive Software Engineering Inc. Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-07-20T00:00:00+00:00 List-Id: When someone resorts to changing the subject header of a thread to "The stupidity of all" those who have analyzed an issue and come to different views, it's a pretty good sign that he has run out of technical arguments. To repeat once again the basic point made in the paper by Jean-Marc Jezequel and myself: it is dangerous and unjustifiable, especially in a mission-critical setting, to reuse a software element without a specification. >From the beginning to the end of the software lifecycle, Design by Contract encourages associating such specifications with everything that you write. The method applies on at least four levels: getting the stuff right in the first place, by writing the software elements (the description of *how* things are done) together with their contracts (*what* they are supposed to achieve); documenting them, through automatic extraction of contracts as the basic information on a class; using the contracts as one of the principal guides to reuse; and applying them to debugging, which becomes less of a blind chase and more of a focused analysis of possible discrepancies between intents (the contracts) and reality (the implementations). None of this automatically guarantees perfection, but it sure helps, as reported in these threads by every poster who had actually used Eiffel, where the ideas of Design by Contract are most directly realized. It is true that to someone who has not really tried it some of the benefits may appear exaggerated, but they're real. Just one case in which an incorrect call to a routine produces a violated precondition (caught right away at testing time, whereas it could in another approach have gone undetected for ages, and caused painful bugs) justifies the investment. In Eiffel development, this happens all the time. The Ariane case provides a textbook example of the dangers of not using contracts. Of course it is easy to dismiss this example through below-the-belt arguments, such as - "Jezequel and Meyer are not aerospace industry experts." True, but it doesn't seem the experts did so well in that case (and this is not the first major example of aerospace software failure either), so perhaps it's time to listen to others. Besides, the official report is clear and detailed enough to enable software professionals, aerospace experts or not, to form their own judgment. - "This is only a pitch for Eiffel". The paper by Jezequel and myself says explicitly that the Ariane disaster was not due to a language problem. In spite of this clear and obvious statement some of the Ada enthusiasts in these newsgroups have mistakenly taken the mention of Ariane as a personal affront on their language. The pitch, if any, is for the method of Design by Contract. That this method is directly reflected in Eiffel as a language, and less easy to apply in Ada, is a fact (and presumably in the case of Ada 95 a conscious design decision), not something to be held against the Eiffel community. - "Design by Contract is being promoted as a cure-all." It's not (not a cure-all, and not promoted as such). But it makes a major contribution. All this is rhetorics and cannot succeed to obscure the basic claim that systematic use of Design by Contract would probably have avoided the crash. Of course like any reconstruction of the past this conjecture cannot be proved, but there is enough evidence in the official report to support it. One can also object that other techniques would also have achieved the same goal, such as heavy-artillery a posteriori quality assurance, but they seem far more difficult and costly than integrating Design by Contract, a simple and easy-to-apply idea, into the design, implementation, documentation, reuse and validation process. Some of the negative reactions seem to recall arguments that were used against the proponents of structured programming in the 70s, and against those of object technology in the 80s. They are probably inevitable (and in part healthy, as they force the methodologists to clarify their ideas, refine them, and avoid overselling). But when a useful methodological principle surfaces, all the rhetoric in the world will not prevent its diffusion. -- Bertrand Meyer, President, ISE Inc., Santa Barbara (California) 805-685-1006, fax 805-685-6869, Web: http://www.eiffel.com, with instructions for free download == ISE Eiffel 4: Eiffel straight from those who invented it ==