Re: Interresting thread in comp.lang.eiffel

["David K Allen" <dkallen@visi.com>]

"Ken Garlington"  wrote
> It keeps getting ignored (I suspect because the question can't be
answered),
> but I'll post this example again. The DbC specification for a module is
> given below. I feel fairly confident that this is considered a good
quality
> example by at least one acknowledged Eiffel/DbC expert.

    ;)

>
>    convert (horizontal_bias: INTEGER): INTEGER is
>       require
>          horizontal_bias <= Maximum_bias
>
> If, as you say, this would cause the project team to go get information
they
> did not already have, then explain what information it would require and
> why.
>
> (My analysis of this DbC specification is in the link noted above).

First, I don't think the  authors intended that this one function would have
prevented the entire disaster.
If they meant that, then I must join you in your critique.
I think they were trying to give an illustration that would convey the
approach of DBC in the context of the disaster. But I can see you were not
impressed <grin>.

Second, as you point out in your critique, the error occurred prior to where
this function would have been used (conversion from FP to Integer).  But  if
you accept my previous remark, then that is not the point of their example.
I admit they chose poorly if they were intending to persuade you, who have
such a command of the details.
But for conversation sake,  and to illustrate the usefullness of DBC, let's
assume that the flaw occured within 'convert' above.  Otherwise, I can't
help you see how DBC helps me think and work.

When I am writing a routine that uses a function (like 'convert'), and I see
a precondition (like hb <= Mb), I say to myself:
"As the client (user) of the routine, I better be prepared to honor its
preconditions or I risk failure."
So I take either of two approaches in such a case. I either choose to test
the precondition myself, before calling 'convert', or I choose to ignore it,
and assume that an error MAY occur in the precondition, and I prepare to
trap the exception that may result and handle the failure.
That is a style point for systems where reliability is important.
But this seeems equivalent in my mind to "protecting the variables."
And the inquiry noted (your footnote (6))

    "It is important to note that the decision to protect certain variables
but not others was taken jointly by project partners at several contractual
levels"

Yes, I know - the reason for this jointly agreed decision was cited as
maintaining CPU performance. My only claim is that if DBC were part of the
coding culture, it would have been less likely that that decision would have
been "jointly" agreed to.  If I were working on high-risk stuff with a team
of others trained in DBC, I can't see that we would reach a consensus to
ignore the warning of a precondition.  It just would not be done without
management overriding us.

Without the DBC guidelines or something equally simple and easy to
understand, I fear that such decisions simply degenerate into very fuzzy
gut-level (is it good enough) decisions.  Although all devleopment
ultimately has that anyway.  I really believe that DBC might have tipped the
balance.

Most importantly, in the practical world in which we work and live, I
consider DBC to be easy to understand and powerful at the same time.
Perhaps the language of the original authors you criticize was too bold or
propgandistic for your taste.
But I'm glad it struck you that way.  I learned more about why I like DBC by
reading your criticisms;)
As I read the inquiry, it strikes me how a team that practices DBC routinely
would have probably made different choices.
But I agree that there were a host of other issues, and DBC alone would not
rescue things.
--
Best Wishes,
David Kreth Allen
Software Consultant
Minneapolis, Minnesota - USA