Re: The stupidity of all the Ariane 5 analysts.

[Bertrand Meyer <Bertrand.Meyer@eiffel.com>]

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