Re: Interresting thread in comp.lang.eiffel

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

Riddle:
    When is a contract not a contract?
Answer:
    When they are two different words representing different concepts but
spelled and/or sounding the same (homonyms).
-----------------------------------------
"Ken Garlington" wrote in separate posts

> Wouldn't both sides have to agree to this contract for it to be legally
> valid?

> You understand, of course, that standard contracts are in fact negotiated?

I think, as Bertrand said earlier, that you two were talking on different
wavelengths.
He was talking "Design By Contract (DBC)" a formal method for designing
reliability into software to faciliate reuse.  It is a method which he knows
very well.
Based on the comments you made above, you were talking business contracts,
which you apparently know very well.
Your remarks are important in the context of business contracts, but they
are confusing in the context of "Design By Contract."
Please don't let the fact that "contract" is used as a metaphor in DBC
confuse you with the true meaning of the method.
Like all metaphors, it simply helps you get started, and adds a certain
flavor to the concepts it describes.  But the concept itself can only be
judged if you understand it accurately.

I certainly welcome your criticism of DBC. You are obviously a clear and
critical thinker with considerable experience in software development.  But
it will be more productive if you base your criticisms on what DBC really is
about rather than what you think it might be.
Instead of reacting to our attempts to explain DBC to you, one piece at a
time, perhaps it will be more useful for you if you read a clear
introduction to DBC which explains what it is really about.
http://www.eiffel.com/doc/manuals/technology/contract/page.html.
Others have tried to explain it, but you counter with examples like those
above which tell me you are criticizing DBC based on the mistaken notion
that it is supposed to perfectly model a business contract.

I can understand the confusion - especially in the context of the Ariane
disaster.  Because, in fact, there are issues of both kinds involved in this
situation.
There is a role for a discussion of "Design By Contract" as Dr. Meyer has
developed it, with the precise meanings of that method.
Then there is also a role for discussing how to design software in the
context of business contracts among multiple contractors and subcontractors
where a conglomerate of different nations are the project sponsors (yikes
what a tough deal!).  Although they can have some relationship, they are not
the same thing.

Applying business principles to the software engineering "Design By
Contract" will not really help much.
Conversely, trying to apply Dr. Meyer's software engineering principles to
the socio-political issues will not help either.
They are two different domains with different principles and techniques.

But the point is that if DBC were a component of the software development
method used to build Ariane, then any attempts to reuse software from a
previous project would force the issue that the new project teams MUST HAVE
the specifications of any modules they intend to reuse.   If that had been
part of the software develoment culture, then the subcontractor would have
required the additional information and the contractor would have gladly
complied and provided it.  This would have reduced, though not eliminated
the "art of guessing how much a contractor must provide to a subcontractor"
which you described earlier.
--
Best Wishes,
David Kreth Allen
Software Consultant
Minneapolis, Minnesota - USA