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=-0.5 required=5.0 tests=BAYES_00,INVALID_MSGID, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: fac41,a48e5b99425d742a X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,a48e5b99425d742a X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,a48e5b99425d742a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,5da92b52f6784b63 X-Google-Attributes: gid1108a1,public From: Ken Garlington Subject: Re: Trust but verify (was Re: Papers on the Ariane-5 crash and Design by Contract Date: 1997/03/31 Message-ID: <33400AD1.1FFA@lmtas.lmco.com>#1/1 X-Deja-AN: 229666694 References: <332B5495.167EB0E7@eiffel.com> <5giu3p$beb$1@news.irisa.fr> <332ED8AB.21E7@lmtas.lmco.com> <5go8nk$ngf$1@news.irisa.fr> <3332C049.2A0F@lmtas.lmco.com> <5gue93$2md$3@news.irisa.fr> <33383A6F.3A5A@lmtas.lmco.com> <5ha171$dck@flood.weeg.uiowa.edu> <3338AA0A.7A79CB24@eiffel.com> <333AB895.1459@lmtas.lmco.com> <5hfdh8$b7d@news-central.tiac.net> Organization: Lockheed Martin Tactical Aircraft Systems Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1997-03-31T00:00:00+00:00 List-Id: Jeffrey W. Stulin wrote: > > Hi there: > > As my father is fond of saying "You�ve got to play the percentages." By > this he simply means that while nothing in life is guaranteed, it is > still a good idea to attempt to arrange matters to give them the best > opportunity of working out in your favor. And that is the answer to > Ken�s questions. > > If the Ariane software engineers had the reuse mindset, NOT the specific > mechanisms of Eiffel, but the design by contract reuse mindset, then > they MAY have written the assertion, and MAY have noticed, while > integrating the modules, that the assertion would not have been met. > > I often specify "impossible" assertions because, human nature being what > it is, the impossible will happen, and it is exactly these non intuitive > circumstances which cause the most trouble. > > Now 95% of what Ken has stated about testing and so forth is perfectly > correct. And indeed there is no guarantee that the MAYs above would have > come to pass. However, it is not unreasonable to speculate that if the > integrators had been trained with emphasis on the problems of reuse, the > specification error might have been found. Perhaps likely to be found is > a bit strong, but I don�t find that stretch much of a sin. > > Furthermore, the papers primary between-the-lines claim, that we better > learn a reuse mindset since we are (finally) entering the age of > software reuse, and that the penalties for a reuse error could be > disastrous, is not a stretch at all. It is simple common sense. > > I also find little fault with the implied notion that Eiffel is the > language which would have had the best chance of finding this particular > error. My reasoning is simple: Eiffel is a thin surface for an idea, > the idea of how to specify and reuse software (design by contract etc.). > That�s what Eiffel is. Now there may be many areas where Ada would have > strengths in solving problems and Eiffel would fall flat on its face. > But not on issues of software reuse. Eiffel is simply the best. > > Finally, I have no problem with Ken�s Putting BM & Co. feet to the > flames. I enjoy seeing ideas stress tested and especially enjoy reading > about the practical view of those involved in a particular industry. I > do, however, object to Ken�s tone in some of his postings. As a reader I > feel that I am being shouted at, and I don�t like it. Please keep > posting Ken, but post calmer. Sorry about that. Paraphrasing Twain: "I would have written calmer, but I ran out of time." I have no stong objection to the claim that I think you're making: that DBC _might_ have improved the odds in this case. However, I think there's a long way to go, for *this particular case*, to make the claim that DBC would _probably_ have avoided the error. Improving the odds to 20%, for example, is still not "probably"! > > Thanks, > > Jeffrey W. Stulin > > -- LMTAS - The Fighter Enterprise - "Our Brand Means Quality" For job listings, other info: http://www.lmtas.com or http://www.lmco.com