Re: Trust but verify (was Re: Papers on the Ariane-5 crash and Design by Contract

[Bertrand Meyer <bertrand@eiffel.com>]

Robert S. White wrote:
 
> So don't think it is just him that has been put off by people
> saying that "Design By Contract with the Eiffel language"
> would have (alone - without simulation or HWIL) testing)
> prevented the [Ariane] 5 disaster.

In this particular case there is good reason to think that good
use of Design by Contract would in fact have evidenced the bug
early in the development cycle, long before any simulation or
testing. I think anyone that has practiced the method will agree.
To repeat the basic point of our (Jezequel's and mine) paper:
do not reuse without a contract.

But of course this is not a reason to say there should not be
simulation, testing, inspections, independent reviews etc. etc.
I don't recall anyone even coming close to suggesting this in the
present thread. And our paper certainly does not say anything of
the sort.

	(By the way I don't primarily think of Eiffel as a "language",
	 more as a method. But this is not the main point of this
	 particular discussion.)
 
> And it is normal industry practice to have different (from the
> designers/coders) personnel do the qualification tests (HWIL) test
> procedures and conduct the tests using the "Black Box" requirements.

Agreed. Not only normal but excellent practice.

I like the modified thread title of your message:
"Trust but verify" although I would make it stronger:
"Make it trustable, then DON'T trust it" (and so verify it).
It would be as absurd to use Design by Contract or other
a priori relability techniques as an excuse not to do a posteriori V & V
(testing, simulation etc.),
as it would be to develop in a sloppy way with the expectation that
testing will uncover any problems.

If a priori reliability techniques - Design by Contract, static typing,
genericity, automatic memory management etc. - were a substitute for
testing, why would Eiffel environments bother to include debugging
tools? Engineering reliability can only result from the combination of
several techniques approaching the product from different angles:
some a priori (building the product right in the first place),
some a posteriori (not believing that it is right, and test it
extensively). That this is not an either-or situation
is so obvious as to be almost a platitude (although one does
encounter people, including software engineering authors,
who believe in only the a priori part or only the
a posteriori part).

But the need for a posteriori verification 
is too often an excuse for not applying the proven a priori
reliability techniques, such as Design by Contract. This is not
only silly but a recipe for disaster of Ariane-5 proportions.

It's been amazing in this discussion how some postings have taken
to task our paper for ideas that are not there.
The points that it makes are pretty simple, and there for everyone
to examine (http://www.eiffel.com, link to "Ariane 5 paper");
after reading most of the discussion, and re-reading the paper,
I think that its arguments and conclusion are perfectly in line with
many useful comments made by people who thought they disagreed with it.
Please check what it really has to say.

-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com
	(including instructions to download Eiffel 4 for Windows)