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: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public From: "Marin David Condic, 561.796.8997, M/S 731-96" Subject: Re: The stupidity of all the Ariane 5 analysts. Date: 1997/08/19 Message-ID: <97081914235478@psavax.pwfl.com>#1/1 X-Deja-AN: 265372143 Sender: Ada programming language Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU X-VMS-To: SMTP%"INFO-ADA@VM1.NODAK.EDU" X-VMS-Cc: CONDIC Newsgroups: comp.lang.ada Date: 1997-08-19T00:00:00+00:00 List-Id: Joerg Rieling writes: >but, a minimum requirement for any software is to test it under >sufficiently realistic conditions, isn't it ? if the responsible >software engineers would have fed _simulated_ data containing some >information about the trajectory into their programs, they could >(would) have found the bug, d'accord ? >sometimes experimental programming is not the worst choice ... > This is exactly the point that has so many people torqued off about the whole debate. (Especially those of us who actually build this sort of software for a living.) The claim seems to be on the table that a) Existing software development practices are insufficient for developing safe software and b) the only way to be sure that you don't blow up a rocket is to use Design By Contract as exemplified by Eiffel. The problem is - as those of us in the business know - existing practices, HAD THEY BEEN FOLLOWED, would have caught the problem. (Your example of testing the software across the expected flight envelope.) So would lots of other existing practices. The problem is that the human beings in charge of the process didn't follow the usual and customary procedures (probably under cost and schedule pressure). Hence, no technology would likely have helped keep them out of the Gulag they are now most likely consigned to. (It's sad too for those of us who have ever experienced the "Hurry up and get it done no matter what the risk..." pressure that can be brought onto a project.) DBC and Assertions, in my not so humble opinion, would have proven to make no significant difference in the situation. DBC is a kind of process and apparently the people in charge were into circumventing processes. So DBC could have as easily been circumvented for the same reasons as they circumvented existing, industry accepted and used processes. (which, IMNSHO, would probably have caught the problem had they been followed.) If you walk a tightrope without a net often enough, eventually you'll splat up against the pavement. Assertions are just another kind of runtime check which - although useful - would probably have made no difference either. The reason being that the existing checks were disabled (for good reason) and so assertions would also have been disabled. Disabled checks don't change anything. The notion that they would have served as documentation implies some kind of review/testing and go back to the above paragraph on DBC. They had already circumvented that part of the game, so forget that argument. The seriously flawed notion that the runtime checks be turned on during testing and then disabled for production only displays lack of knowledge of how flight qualified software is really built. Nobody is going to go through any sort of serious verification of a software package only to allow you to change some of the bits afterwards and claim "well, it's really the same thing so let's go fly with it..." That might be O.K. for testing something like Microsoft Word, but it will never pass muster for safety critical software. Hence, you run with them in or you run with them out. Running with them in might have done something to save the day - but then so would the existing range checks that were taken out. MDC