Re: Critique of Ariane 5 paper (finally!)

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

Note: Invectives ("complete nonsense", "bogus", "absurd" etc.)
serve no useful purpose. In particular they are not a
substitute for arguments. We are all very passionate
about these things, which is good, but I think we should
all continue to accept that the other side is not
completely incompetent. I certainly respect Robert
Dewar's views, even those (not all) with which I
disagree. (End of note.)

Robert Dewar initially wrote

> > reliability is measured in the terms that matter, i.e.
> > it does what it is supposed to do in a highly reliable manner.

which says little more than: a system is reliable if it is
highly reliable. It would be hard to quarrel with his statement,
but as a definition it's not very useful. He then refined
this definition into

> I said that the
> only measure of reliability that made any sense was that a program
> behaved in a realiable manner and did what it was supposed to do

Again, probably true but not sufficient as a definition. The
first part is a tautology (a program is reliable if it behaves
in a [reliable] manner -- sure). The second part, "[does] what is
supposed to do", is broadly correct as a general, informal
definition (although even so one can do better, in particular
by distinguishing between two components of reliability,
correctness and robustness), but is not enforceable in any way.
How do you know that a system "does what it is supposed to do"?
The most you can expect (in the absence of formal techniques) is,
as I wrote in my earlier message, that the program has "done
what it is supposed to do" for a certain period of time,
be it 30 seconds or 30 years.

        (And even that is subject to doubt,
        as you can hardly be sure that everything was perfectly
        all right. For example if we take one of the pragmatically
        reliable COBOL programs that Prof. Dewar cites, assuming
        it has been computing payroll taxes for the past 10 years,
        few people would bet $50,000 of their own money that no one
        will sue and win damages on the basis of wrongful operation
        of the program during that past period.) 

These are difficult issues and no one has a silver bullet. But
it turns out that it is possible to do better at least
at the component level. As Prof. Dewar has correctly pointed
out, specifying the behavior of a complete system -- i.e.
"what it is supposed to do" -- is hard. But for a component
of that system it is often possible to write such a specification,
partially or totally formal. This is what Design by Contract is
about.

The claim that it is necessary has an obvious basis: you can't
get the system right if you can't get the components
right. To get the components rights, you need to convince enough
people, beginning with yourself, that they are
"doing what they are supposed to do", and you can't do
that without stating what they are supposed to do,
as precisely as possible. The good news is that for a
component you can realistically be more precise than for
a whole system.

The more fundamental issue is that we need better ways
to achieve the reliability of mission-critical systems.
Not just better organization and management, but better
techniques. Design by Contract is one such technique. It
is not by itself the answer, but I think it is a required part
of the answer.


-- 
Bertrand Meyer