The stupidity of all the Ariane 5 analysts.

The stupidity of all the Ariane 5 analysts.

[Thaddeus L. Olczyk]

Frankly I'm getting a little tired of all the stupidity of the language
enthusiasts
and methodologists who are out there saying "Ariane 5 crashed because they
didn't use my language or my methodology". They are all ignoring one basic 
fact: the backup and primary systems were identical. Effectively this meant
that most bugs or generic hardware defects were likely to be duplicated,
eliminating
most of the safety that a backup system provides.

While not strongly conversant in the design of fault tolerant systems, I do
know
that some systems use backups which are the same and others use backups
which are entirely different ( different hardware, software, and
methodology ).
I believe that it doesn't take a rocket scientist to figure out that among
the later
are thingfs like: missle launching systems, remote facilities and rockets.

Re: The stupidity of all the Ariane 5 analysts.

[Bertrand Meyer]

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, <Bertrand.Meyer@eiffel.com>
Web: http://www.eiffel.com, with instructions for free download
== ISE Eiffel 4: Eiffel straight from those who invented it ==

Re: The stupidity of all the Ariane 5 analysts.

[Robert S. White]

In article <33D2827B.41C67EA6@eiffel.com>, Bertrand.Meyer@eiffel.com says...
>
>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.

  We "aerospace" people agree.


>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.

  The problem with this is that you are preaching to the choir.
Long long ago, before Eiffel, the general concept of capturing
system requirements in a spec document, flowing down to a software
requirements document, conducting detailed design reviews with the
requirment documents as resources/authorities (or getting them 
updated) and finally having software qualification tests done to 
prove performance to the software requirements spec has been 
practiced by the "aerospace" industry.  The "crash" resulted 
because of a failure to fully follow this existing practice.  
Your papers about Eiffel and Design By Contract are just, IMO,
another way to implement the concept of developing software that
must comply to requirements.

_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer

Re: The stupidity of all the Ariane 5 analysts.

[Ian Begg]

On Sun, 20 Jul 1997 14:26:19 -0700, Bertrand Meyer
<Bertrand.Meyer@eiffel.com> wrote:

<snip>

>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.

My personal opinion, I would add ".... or, probably more importantly,
without fully testing that software element in the environment it is
being re-used into, i.e. under the conditions it is expected to be
used in."  My understanding is that the expected flight profile was
not flown as part of the integration or acceptance testing, and that
had this been done the problem would (probably) have been found.  This
is what I mean by testing in the environment it is being re-used into.

<snip>

>	- "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 ...

Even clear and obvious statements have to be assessed to decide on the
intent of the author/speaker, for instance is he saying this because
he means it or because he's trying to pull the wool over our eyes.  [I
have not read your report so have no idea how to answer in this case,
everyone must make their own decision.  The author must ensure they
don't leave themselves open to the wrong interpretation.]

>                                                                                ... 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. 

How many languages support Design by Contract as part of the language
as in the case of Eiffel?  I don't have experience of a broad range of
languages so I can't answer this.  However, if the answer is only
Eiffel, (plus perhaps some other non relevant langauges) then it is
not difficult to see how people might interpret your motives as "OK we
can't be so obvious as to say Eiffel is the answer, but if we say
Design by Contract is the answer, people will need to find a language
to support it, hence Eiffel."  You are the only person who knows your
real motives, but the discussions going on suggest some people are
interpreting your motives in this way.

<snip>

>    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.

How easy is this to apply in non Eiffel implementations?  I guess it
needs extra work by the engineers, in an area most are probably not
familiar with and will hence need training, and success is dependent
on setting up good procedures to enforce its use etc.  Compare the
cost of that with doing integration and acceptance testing under
anticipated use conditions which should be done anyway and I come to
the conclusion use of Design by Contract was not the best way of
preventing this accident.

This is all of course my own personal opinion, and none of it should
be read as an 'attack' on anyone elses opinions, only a difference of
opinion.  Sorry if this is repeating stuff from the original thread(s)
which I have not been tracking closely.

Ian Begg

Re: The stupidity of all the Ariane 5 analysts.

[Robert Dewar]

Bertrand said

<<>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.
>>

Well all sorts of things would have avoided the crash. One can also say
that systematic proof of correctness, or systematic code review, or
in fact almost any steps to be a bit more careful in this particular
area, would have avoided the crash. As usual, a disaster of this type
is a chain of occurrences, and fixing any one of them would have avoided
the problem.

Certainly the notion of clear interfaces and interface requirements
(I find the use of the capitalized "Design by Contract" a little 
pretentious, since I see no new concept there that justifies a new
technical term) is one which we can all agree on.

The argument that the use of Eiffel would have prevented the problem is
entirely unconvincing, and has the unfortunate effect of encouraging
people to think that the entire argument is just empty language advocacy.


When there is a major screwup in software (some examples, the long lines
failure at AT&T, the Denver baggage handling, the overnight funds transfer
disaster in an NY bank etc), there is a natural tendency for over
enthusiastic pushers of a particular language to try to argue that
their particular pet language would have guaranteed freedom from the
problem.

Such arguments are never convincing, because even if it *were* the case
that the particular problem at hand might *possibly* have had a better
chance of being avoided writing in language X, extending this to the
allegation that the use of language X would in general have been beneficial
stretches credibility. In particular, in a large complex system of this
type, the language and all other components have to meet all kinds of
complex requirements, and people who know nothing at all about the whole
application have no idea whatsoever if their pet language would in fact
meet the criteria.

If Bertrand is saying:

(a) The Ariane problem (at least little piece of it) is a good example of
why designing interfaces that are complete with respect to establishing
a requirements contract for clients is a good idea.

(b) One of the attractive features of Eiffel is that it supports this
concept directly and encourages programmers to use this approach.

Then the argument is entirely reasonable, and one that I cannot see
anyone objecting to. But the way the argument is stated, it reads as
though he is saying:

If Eiffel had been used for the Ariane project, it would not have crashed.

And I find that claim entirely unjustified, and it detracts from the
important underlying point.

No language can force people to do things right, and to a large extent
no language prevents people from doing things right. What a language
can do is to encoruage a style of programming and thinking that helps
people find their way to doing things right a little more easily.


This is indeed the principle behind the Ada design, and a lot of the
reason that Ada is successful in practice is precisely because it
encourages "good thinking". 

But when people said "if only the Denver baggae system had been written
in Ada, I would be flying to the new airport today", this crossed the
line into non-credible language advocacy.

Similarly, a lot of the thinking behind the Eiffel design is also
to encourage "good thinking", and in that sense Ada and Eiffel are
kindred spirits in their approach to language design, though they
make different choices about what is important to encourage.

However, when the Eiffel advocacy crosses the line to saying that a large
complex system, if written in Eiffel, would have succeeeded where otherwise
it failed, again this crosses the line into non-credible language advocacy.

I am, as everyone knows, a strong advocate of the use of Ada. However, I
take a lot of care NOT to make exaggerated claims, since I don't think
this helps at all. What Ada (or any other language) can do, is to push
programmers up a little bit on the quality and productivity scales.

A little bit may not sound like much, but these scales are logarithmic
scales in which the productivity of programmers and the quality of the
code they right varies over orders of magnitudes, so a "little bit" can
add up to very substantial savings in costs, and very substantial
improvements in quality in practice. 

Re: The stupidity of all the Ariane 5 analysts.

[Ken Garlington]

Robert S. White wrote:
> 
> The "crash" resulted
> because of a failure to fully follow this existing practice.

Yes, I agree. (I decided not to address the statement in the Eiffel
paper that says the opposite, it seemed to be piling on.)

Hope you get a chance to review my draft critique. Geoff Eldridge
<geldridg@progsoc.uts.edu.au> was kind enough to create an HTML
version at:

   http://www.progsoc.uts.edu.au/~geldridg/eiffel/ariane/

BTW, I just noticed the flaws in the example Eiffel code at the
last minute (midnight Saturday, in fact). Did you and everyone
else know it was wrong, and just not say anything, or did we
all overlook the errors?

 _____________________________________________________________________
> Robert S. White         -- An embedded systems software engineer

Re: The stupidity of all the Ariane 5 analysts.

[Ken Garlington]

Bertrand Meyer wrote:
> 
> 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.

Geoff Eldridge <geldridg@progsoc.uts.edu.au> was kind enough
to post my draft critique of your paper in HTML format at:

   http://www.progsoc.uts.edu.au/~geldridg/eiffel/ariane/

Let me know if you have any comments before I submit the final
version to you at the end of the month. Thank you.

Re: The stupidity of all the Ariane 5 analysts.

[W. Wesley Groleau x4923]

> Your papers about Eiffel and Design By Contract are just, IMO,
> another way to implement the concept of developing software that
> must comply to requirements.

He/they start from the (obviously debatable) belief that 
"'ideas of Design by Contract are most directly realized' in Eiffel" 
and then make an unjustified jump to 
"if it doesn't look like Eiffel, it doesn't do Design By Contract."

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: The stupidity of all the Ariane 5 analysts.

[Robert S. White]

In article <33D3F2CB.61DC@flash.net>, kennieg@flash.net says...

>BTW, I just noticed the flaws in the example Eiffel code at the
>last minute (midnight Saturday, in fact). Did you and everyone
>else know it was wrong, and just not say anything, or did we
>all overlook the errors?


Do you mean what you addres in your Critique's paragraph 3.1.1 about
Meyer's Eiffel paper's solution code:

"...any software element that has such a fundamental constraint should 
state it explicitly, as part of a mechanism present in the programming 
language, as in the Eiffel construct

      convert (horizontal_bias: INTEGER): INTEGER is
            require
                  horizontal_bias <= Maximum_bias
            do
                  ...

            ensure
                  ...

            end

where the precondition states clearly and precisely what the input must 
satisfy to be acceptable."

  Yes it looks like the above code should do a floating point absolute
value on horizontal_bias before it checks against Maximum_bias.  But
I consider that a _typical_ coding error that is normally found by software
code inspections or unit level tests - whoops - DBC/Eiffel does _not_
find this error!  And yes, the test _must_ be done while the value is
still expressed in floating point _before_ conversion to integer...details,
details.  Stuff we encounter all of the time in our problem domain.

  One could argue that the above is just a nit (flawed example) and 
the overall premise of DBC/Eiffel as a "silver bullet" panacea versus
conventional "aerospace industry software engineering process" is 
the real issue.
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer
                  (newsgroups trimmed to contain the "language wars")

Re: The stupidity of all the Ariane 5 analysts.

[Joerg Rodemann]

Bertrand Meyer (Bertrand.Meyer@eiffel.com) wrote:
> 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.

Agreed: it should be clearly stated what something is intended for. Although
the idea of preconditions sound very good to me at first sight I am very
sceptical if this is very useful at all since one has to think of EVERY
possibility the routine might be used for. E. g. assume the implementation
of some mathematical function that is not well defined for the complete
complex plane or not continously defined for real numbers. On the other
hand you might have an algorithm at hand that is suitable for every value
the function is defined. (Maybe the Gamma, Beta and Zeta functions are
some examples that meet my assumptions --- I can't remember them exactly right
now.) On the other hand you know that for your actual problem this function
is indeed defined for each possible value since you are --- from your
requirements --- quite sure that some area will not be left. So you could
enter this as a precondition. 

But now guess you like to use this component for some other work --- and 
you are not dealing with complex numbers of different areas of the plane.
It seems to me that you list of preconditions will grow very fast ---
leaving the code quite unreadable. (Kind of a " i++;  // increments i" type
comment.) Code is the more difficult to comprehend the large it is. And
especially emphasizing details may obscure the essential parts. Was not
this abstraction was all about?

From this point of view I would think that easy checkable preconditions
should be checked (e. g. using assertions). Others should be kept in the
documentation. As far as Ariane V is concerned the report clearly states
that the problem was know and discussed during develepment but due to
cpu time limits not every suspected variable was covered. It seems to me
that a lack of knowledge about the actual application was one reason for
the error to occur. (Among the devastating assumption that exceptions are
only to occur when hardware fails!) No pre-/postcondition theology would have
cured that, IMHO. (I believe no methodology could cure that. and this might
be a problem that is not easy if at all to solve for systems that complex.)

Well, just my humble opinion...and I have to admit that I have no experions
within realtime or safety critical applications development.

Yours sincerly

Joerg


--
rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670     | Flurstrasse 21, D-70372 Stuttgart, Germany
-------------------------------+---------------------------------------------
rodemann@rus.uni-stuttgart.de  | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5815    | Visualization Department, Office: 0.304
Fax:   ++49-(0)711-678-7626    | Allmandring 30a, D-70550 Stuttgart, Germany

Re: The stupidity of all the Ariane 5 analysts.

[Ken Garlington]

Robert S. White wrote:
> 
> In article <33D3F2CB.61DC@flash.net>, kennieg@flash.net says...
> 
> >BTW, I just noticed the flaws in the example Eiffel code at the
> >last minute (midnight Saturday, in fact). Did you and everyone
> >else know it was wrong, and just not say anything, or did we
> >all overlook the errors?
> 
> Do you mean what you addres in your Critique's paragraph 3.1.1 about
> Meyer's Eiffel paper's solution code:
> 
> "...any software element that has such a fundamental constraint should
> state it explicitly, as part of a mechanism present in the programming
> language, as in the Eiffel construct
> 
>       convert (horizontal_bias: INTEGER): INTEGER is
>             require
>                   horizontal_bias <= Maximum_bias
>             do
>                   ...
> 
>             ensure
>                   ...
> 
>             end
> 
> where the precondition states clearly and precisely what the input must
> satisfy to be acceptable."
> 
>   Yes it looks like the above code should do a floating point absolute
> value on horizontal_bias before it checks against Maximum_bias. 

Yes, this is what I mean.

> But
> I consider that a _typical_ coding error that is normally found by software
> code inspections or unit level tests - whoops - DBC/Eiffel does _not_
> find this error!  And yes, the test _must_ be done while the value is
> still expressed in floating point _before_ conversion to integer...details,
> details.  Stuff we encounter all of the time in our problem domain.

It would have been found if the design made it clear a different
solution
was necessary, or "common sense" was used in this example.

>   One could argue that the above is just a nit (flawed example) and
> the overall premise of DBC/Eiffel as a "silver bullet" panacea versus
> conventional "aerospace industry software engineering process" is
> the real issue.

However, I think there's a fundamental point made by this "nit." Several
people read the paper; in fact, I saw one example in DejaNews last year
where someone posted the Ada version of this code... incorporating the
same mistakes! No one, as far as I could tell, saw this "obvious" error
in three lines of code despite many months of opportunity. What does
this
say about the credibility of manual inspections at the source code level
in picking up errors of this type during the reuse of software?

> _____________________________________________________________________
> Robert S. White         -- An embedded systems software engineer
>                   (newsgroups trimmed to contain the "language wars")

Re: The stupidity of all the Ariane 5 analysts.

[Robert Dewar]

Robert White said

<<  One could argue that the above is just a nit (flawed example) and
the overall premise of DBC/Eiffel as a "silver bullet" panacea versus
conventional "aerospace industry software engineering process" is
the real issue.
>>

Unfortunately the Ariane crash was the result of just such a nit!

I would think experience would teach us to be very suspicious of any
claims by anyone to have a silver bullet panacea wjhen it comes to
software engineering for large systems.

However tools and techniques that help, even a little bit, are welcome
even if they are not a panacea (I consider Ada to be in this category,
and I always find it annoying when people advertise Ada as being
a silver bullet panacea).

Re: The stupidity of all the Ariane 5 analysts.

[Ken Garlington]

Robert Dewar wrote:
> 
> Robert White said
> 
> <<  One could argue that the above is just a nit (flawed example) and
> the overall premise of DBC/Eiffel as a "silver bullet" panacea versus
> conventional "aerospace industry software engineering process" is
> the real issue.
> >>
> 
> Unfortunately the Ariane crash was the result of just such a nit!
> 
> I would think experience would teach us to be very suspicious of any
> claims by anyone to have a silver bullet panacea wjhen it comes to
> software engineering for large systems.
> 
> However tools and techniques that help, even a little bit, are welcome
> even if they are not a panacea (I consider Ada to be in this category,
> and I always find it annoying when people advertise Ada as being
> a silver bullet panacea).

I agree with this, but I also think every tool and technique has both
advantages _and risks_. Failing to understand the risks, and where they
are (and aren't) important, can lead to extremely dangerous choices made
with the best of intentions. I view executable assertions (Ada, Eiffel,
etc.) in this category. In some environments, they are clear wins. In
other
environments, I think it is at least debatable whether their advantages
outweigh their risks.

Complicating this factor is that many people confuse the abstract Good
Thing
(e.g. well-documented assumptions) with a specific implementation of the
Good Thing. They consider the Good Thing so obvious that they don't
consider
(a) what Bad Things may also be associated with the _implementation_ --
the
proponents of the implementation aren't always candid about this part
(or are
sometimes just blind to it) and (b) whether, for a given project, there
are better
ways to achieve the Good Thing.

As you've said in the past, Computer Science is in part a misnomer in
that
there doesn't seem to be much in the way of controlled experiments. So,
a
lot of these risk/reward analyses are based on incomplete data, at best.
This doesn't mean that they shouldn't be done, however. Ignoring the
risks
(or worse, dismisssing them as "they just haven't seen the light yet,"
as
Mr. Meyer did recently) is not smart in any environment, and certainly
not
in safety-critical systems.

Re: The stupidity of all the Ariane 5 analysts.

[Robert S. White]

In article <33D69CAF.19F1@flash.net>, kennieg@flash.net says...

> Robert S. White wrote:
>> I consider that a _typical_ coding error that is normally found by software
>> code inspections or unit level tests

>It would have been found if the design made it clear a different
>solution
>was necessary, or "common sense" was used in this example.

  Perhaps I should have provided more detail about our industry
software engineering process.  During the detail design review of 
the software module, Test Cases, for doing the module unit level
tests are also presented.  One of the checklist items for the test
cases is to ensure that the module is tested at boundry conditions
and beyond boundry conditions - both for the positive and negative
extremes in the case of a signed value.  This type of software
design process with inspections using checklists even against the
test cases is a way to spread out that very rare/precious commondity
called "common sense".
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer

Re: The stupidity of all the Ariane 5 analysts.

[Shmuel (Seymour J.) Metz]

Robert Dewar wrote:
> 
> I would think experience would teach us to be very suspicious of any
> claims by anyone to have a silver bullet panacea wjhen it comes to
> software engineering for large systems.
> 
> However tools and techniques that help, even a little bit, are welcome
> even if they are not a panacea (I consider Ada to be in this category,
> and I always find it annoying when people advertise Ada as being
> a silver bullet panacea).

I would go farther; I am suspicious of anyone who advocates a particular
languages and can't tell me anything in the language that he dislikes.
If
he can't identify flaws, either he's too inexperienced to rely on or 
isn't perceptive enough. *any* programming language will have warts, and
a real professional will recognize them and have strategies for dealing 
with them.

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz.

Re: The stupidity of all the Ariane 5 analysts.

[Al Christians]

It occurs to me that DBC is less than 100% applicable in this case.  As
I read it, contracts constrain the terms of interaction between clients
and servers, and as I recall, the server should expose to the client all
the methods it uses to evaluate preconditions, so that the client can
verify its compliance before requesting the service.  In the case of the
Ariane, however, the client was hardware, some kind of dumb sensor that
took physical measurements and sent them into the machine, with no real
interest in what came out later, and not enough neurons to figure out if
it was in compliance with any set of preconditions or not.  So why
should the server bother to check preconditions in this case -- after
all, the client doesn't give a rusty, so why should the server?  Who's
he gonna call? If that's a contract, then my roof is a contract between
my house and the sky.   The guys who built the roof didn't know what
wind speed it was supposed to withstand, they just built it the way they
always build them, and that's good enough.  And if the roof is spec'd to
handle winds up to 80 mph, I'm figuring that if one comes along at 85
mph, the roof isn't going to shut itself down on account of a contract
violation, it's going to try its best to hold together anyway, which is
what I'd want. OTOH, the software on the Ariane did shut itself down
while the thing was in flight, didn't it?

It would be nice if there could be a clear spec that includes everything
that might happen in the real world,  but when the real world does
something that the spec didn't anticipate, do we want the software to
just curl up and die?

Al

Re: The stupidity of all the Ariane 5 analysts.

[Robert Dewar]

Shmuel says

<<I would go farther; I am suspicious of anyone who advocates a particular
languages and can't tell me anything in the language that he dislikes.
If
he can't identify flaws, either he's too inexperienced to rely on or
isn't perceptive enough. *any* programming language will have warts, and
a real professional will recognize them and have strategies for dealing
with them.
>>

Of course, that goes without saying, but did you ever meet anyone who was
in that category whose ideas you would otherwise respect. I know some
people who display this kind of ignorance, but they are not the kind of
people I would take seriously.

You can say the same thing about operating systems of course, for example
anyone who cannot point out the flaws in XXX, simply indicates that they
do not know the system very well, or that they lack the experience to
know that improvements are possible

(XXX = NT, Unix, Win95, OS/2, VMS etc etc)

Re: The stupidity of all the Ariane 5 analysts.

["Paul E. Bennett"]

In article <33E06929.59F6@easystreet.com>
           achrist@easystreet.com "Al Christians" writes:

> 
> It would be nice if there could be a clear spec that includes everything
> that might happen in the real world,  but when the real world does
> something that the spec didn't anticipate, do we want the software to
> just curl up and die?

If such a spec could be produced it would probably be too large to 
understand in reasonable time. Instead, we need to construct our systems 
so that out-of-the-ordinary stimulii do not cause un-expected activity of 
the system. This involves knowing what happens in the system when the 
stimulii exceed the design limitations. This takes some effort in FMECA
and the designing in of "Inherent Robustness" for the system to become
dependable.

If we are going to re-use components, we need to be more certain about
what the effects are for component failure. In the A5 flight systems
situation, there were other factors in the organisation which blindly 
accepted the decision for non-provision of flight profiles. A risk 
assessment for the decision should have been conducted to determine if 
this was a reasonable decision.


-- 
Paul E. Bennett ................... <peb@transcontech.co.uk>
Transport Control Technology Ltd.   <http://www.tcontec.demon.co.uk/>
+44 (0)117-9499861                  <enquiry@transcontech.co.uk>
Going Forth Safely

Re: The stupidity of all the Ariane 5 analysts.

[Shmuel (Seymour J.) Metz]

Robert Dewar wrote:
> 
> You can say the same thing about operating systems of course, 

In fact, I *do* say the same sort of thing about operating systems. ;-)

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz.

Re: The stupidity of all the Ariane 5 analysts.

[Ken Garlington]

Paul E. Bennett wrote:
> 
> In article <33E06929.59F6@easystreet.com>
>            achrist@easystreet.com "Al Christians" writes:
> 
> >
> > It would be nice if there could be a clear spec that includes everything
> > that might happen in the real world,  but when the real world does
> > something that the spec didn't anticipate, do we want the software to
> > just curl up and die?
> 
> If such a spec could be produced it would probably be too large to
> understand in reasonable time. Instead, we need to construct our systems
> so that out-of-the-ordinary stimulii do not cause un-expected activity of
> the system. This involves knowing what happens in the system when the
> stimulii exceed the design limitations. This takes some effort in FMECA
> and the designing in of "Inherent Robustness" for the system to become
> dependable.

Also, FMECA/FMET is quite valuable in that it usually is not solely
driven
by the specification, but also includes past experience driven from
failure
records. We've found FMET in particular to be quite useful in finding
holes in the specification.

> If we are going to re-use components, we need to be more certain about
> what the effects are for component failure. In the A5 flight systems
> situation, there were other factors in the organisation which blindly
> accepted the decision for non-provision of flight profiles. A risk
> assessment for the decision should have been conducted to determine if
> this was a reasonable decision.
> 
> --
> Paul E. Bennett ................... <peb@transcontech.co.uk>
> Transport Control Technology Ltd.   <http://www.tcontec.demon.co.uk/>
> +44 (0)117-9499861                  <enquiry@transcontech.co.uk>
> Going Forth Safely

Re: The stupidity of all the Ariane 5 analysts.

[Larry Kilgallen]

In article <dewar.870362889@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> You can say the same thing about operating systems of course, for example
> anyone who cannot point out the flaws in XXX, simply indicates that they
> do not know the system very well, or that they lack the experience to
> know that improvements are possible
> 
> (XXX = NT, Unix, Win95, OS/2, VMS etc etc)

I think blindness to flaws has more to do with inexperience in
_other_ environments than in the one under discussion.

If my experience is limited to languages without uplevel addressing
(e.g., Bliss, C) I will not see that as a shortcoming the way I
would if I had used other languages (Ada, Pascal).

Larry Kilgallen

Re: The stupidity of all the Ariane 5 analysts.

[Don Harrison]

This is a response to something posted to comp.lang.ada but not comp.lang.eiffel..

"Shmuel (Seymour J.) Metz" wrote:

:Robert Dewar wrote:
:> 
:> I would think experience would teach us to be very suspicious of any
:> claims by anyone to have a silver bullet panacea wjhen it comes to
:> software engineering for large systems.
:> 
:> However tools and techniques that help, even a little bit, are welcome
:> even if they are not a panacea (I consider Ada to be in this category,
:> and I always find it annoying when people advertise Ada as being
:> a silver bullet panacea).

Me too. :)

:I would go farther; I am suspicious of anyone who advocates a particular
:languages and can't tell me anything in the language that he dislikes.

Presumably, you're talking about me. :)

If you think I never have any criticisms of Eiffel, you're mistaken. What may 
surprise you even more is that I sometimes have positive things to say about
Ada! - for example, two recent posts to comp.lang.eiffel under the subject
"Ennumerations in Eiffel" (31.7.97 and 1.8.97). These included two criticisms
of Eiffel and one positive comment about Ada.

Also, was my agreement with criticisms of Eiffel WRT use of assertions and GC
in hard realtime software a glowing endorsement of Eiffel? I think not.

:If he can't identify flaws, either he's too inexperienced to rely on or 
:isn't perceptive enough. 

Thank you. :)

:*any* programming language will have warts, 

Eiffel has its flaws; it's just that Ada has about 50 times more. :)

:and a real professional will recognize them and have strategies for dealing 
:with them.

Agree.


BTW, one the few areas where Ada is streets ahead of Eiffel (and most languages), 
IMO, is standardisation. While Eiffel does have a standard language and libraries, 
not all vendors comply with them. Part of the problem is that there is no 
official certification of Eiffel compilers and, hence, no validation suite as 
there is in Ada. Obviously, this causes portability problems. 

Just because someone is biased, doesn't mean they can't also be honest and 
objective. Also, one can be biased with or without justification.


P.S. It shows considerably more intestinal fortitude to criticise someone to 
their face rather than where you don't think they'll hear you. Even if they 
don't agree with what you have to say, they may at least respect you for not
saying it behind their back. :(


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: The stupidity of all the Ariane 5 analysts.

[Shmuel (Seymour J.) Metz]

Don Harrison wrote:
>
> Presumably, you're talking about me. :)

Assuming that your name is legion ;-)
 
> P.S. It shows considerably more intestinal fortitude to criticise someone to
> their face rather than where you don't think they'll hear you. Even if they
> don't agree with what you have to say, they may at least respect you for not
> saying it behind their back. :(

Let's see; I post a public message in a forum in which you have been 
participating, and that constitutes saying it behind your back? If you
think 
that I should have sent you an E-mail, plenty of people have been flamed
for 
doing just that, on the grounds that is was an additional copy of a
message that
would already have been read by virtue of having been posted. I am
generally 
very sparing of cc headers in Usenet, and see nothing in my message to
justify ending you an extra copy.

Further, since the comment applied to multiple messages in the thread, I
would 
have had to search out all of the others to get their addresses and
include them 
on the cc header. Or did you think that you were more important than the
others?
 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

BTW, why on earth would I include a signature block if I were attempting
to 
criticize someone behind their back?

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz.

Re: The stupidity of all the Ariane 5 analysts.

[Joerg Rieling]

hi all,

ok, i perfectly agree with some of the points you made concerning
inherent robustness etc etc etc.

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 ...

bye

j"org.

--
<---->


(- PGP key available.-)

Re: The stupidity of all the Ariane 5 analysts.

[Robert S. White]

In article <5ta2e6$itn$1@enterprise.desy.de>, joerg@hera-b.desy.de says...
>
>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 ?

  That has been _exactly_ one of my positions as an INS (IRS) 
practitioner!  Who exactly are you addressing your comments to?  BM, 
JY, or DH?  The other problem, as pointed out, has been that there 
was software re-use without a correct analysis of its suitability 
by problem domain experts.  A system requirements review with the 
involvement of the right problem domain experts _could_ have 
determined by analysis whether the Ariane 4 IRS software should 
have been reused as is.  The failsafe for this review _should_ have
been proper simulation testing as you describe.
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer

Re: The stupidity of all the Ariane 5 analysts.

[Marin David Condic, 561.796.8997, M/S 731-96]

Joerg Rieling <joerg@HERA-B.DESY.DE> 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