|
»
»
« Return to Thread: DbC question - duplicated contracts
RE: Re: DbC question - duplicated contracts
by rfo
::
Rate this Message:
Howdy!
All good points, well stated.
Another important aspect of contracts is that they constitute a (verifiable) specification. No doubt when your coworkers hear "specification", the flinch a little but perhaps you can explain that good contracts in the code will free them of separate (unmaintainable) specfication chores (everybody loves a bargain). As teams grow and separate, contracts remain and serve to specify the interface between teams as much as between components. Most organizations will have different groups working on different layers (or components) and so having contracts at each layer and in each component provides a built-in mechanism for reducing inter-team management overhead. The upper-layer teams become clients (in real world terms) of the lower-layer teams and so the in-code contracts serve to specify and enforce the human-layer contracts, making for a much smoother relationship. The lower-layer teams can choose any implementation method they desire, as long as it fulfills their customer's (the upper-layer team's) defined requirements (the contracts).
Contracts' value as "finders" w/r/t implementation flaws is huge of course, but let's also remember their net effect on system complexity. A well balanced contract (as elegantly illustrated in Jim McKim's and Brian Henderson-Sellers's "Contracting - What's in it for the Supplier?") results in the minimal complexity. Your team might have bought into this notion already, but a gentle reminder every once in a while can't hurt.
It might also be helpful to note that the belief that a given contract is superfluous is seen by some (me) as irrefutable proof of "POOP" (procedure-oriented object programming). "I know that this is the sequence of instructions, so I need not do this again" is a sound observation in a truly procedural system (it's what allows us to build optimizers). The problem is that component systems are not procedural even if individual components are. Engineers love to criticize Marketing types every time they say "all you have to do is ...", but that seems to be exactly what engineers are saying when dimissing the need/value of contracts at every layer. Save the "all you gotta do is" for within the loop or function, but don't paint the whole system with the same brush.
As for the turn-off-later approach, it too can be layered to match your system architecture. If you arrange you layers into a cluster-like grouping, then the compile-time and run-time switches can be turned off at each layer as needed or desired.
Now that you have introduced DbC, you've opened up a world of possibilities for product and process improvement. DbC will in time allow you to streamline your operations and give back to your developers more high-quality time. They'll become more productive and more personally satisfied with their work (really). They won't believe this until they see it of course (none of us would).
Keep up the good work
R
==================================================
Roger F. Osmond
----------------------------------------
Amalasoft Corporation
273 Harwood Avenue
Littleton, MA 01460
> -------- Original Message --------
> Subject: [eiffel_software] Re: DbC question - duplicated contracts
> From: "colinlema" <clemahieu@...>
> Date: Sat, May 17, 2008 1:34 am
> To: eiffel_software@...
>
> It also might help to point out that contracts will not be in the
> system once finalized. Their purpose is for development for the
> reasons stated before. When the system is finalized the trust is
> established that the low levels will do their jobs correctly, not
> during development.
>
> --- In eiffel_software@..., "streborg" <streborg@...> wrote:
> >
> > Hi, I am trying to introduce DbC to our developers (albeit using
> > Java...one step at a time ! ;) ) ...and am finding that there is
> > resistance at a certain level, that applying it in what I think is a
> > rigorous manner is seen as needless, and going too far.
> >
> > A typical situation is when a function calls a "lower level" function
> > which does the "real work". It is thought that we are just
> > duplicating contracts needlessly.
> >
> > For example, we have various layers in our software - domain,
> > application, UI, data. At the application level, say, we have
> > a "store" function (which stores some kind of object to the
> > database). To achieve its goal, it calls a corresponding data
> > layer "store" function. The application layer store function
> > basically does some transforming of the object to an appropriate
> > format (from a DTO do a domain object), and then calls the data layer
> > store function.
> >
> > So, to my way of thinking, the contracts (just concentrating on
> > postconditions here) are quite straightforward. The application layer
> > store method will guarantee that the object gets stored. The data
> > layer store method pretty much also guarantees the same thing. (There
> > will be various differences too, as well as in the preconditions, eg,
> > dealing with the different formats).
> >
> > So, if we have similar postconditions at these 2 levels, it is seen
> > as pointlessly duplicating them.
> >
> > However, the way I see it is that is is perfectly ok to do this.
> > After all, they do in fact do similar things. Also, contracts are for
> > specifying WHAT is done, not HOW. So, for writing contracts, we
> > should be oblivious to how the function is fulfilling its
> > postconditions (in this case by calling the lower level store
> > function) and simply concentrate on WHAT should be true after the
> > function has done its job.
> >
> > Also, "duplicating" the postconditions is building up internal
> > consistency within the application.
> >
> > Colleagues are arguing that we should look at what the function is
> > doing, ie calling the lower level store function, and because it has
> > the postcondition that it will store the object, then we
> > should "trust" it to do its job, and not bother duplicating the
> > postcondition at the application layer.
> >
> > To me this totally goes against the idea that the contracts are
> > stating WHAT should be done, not HOW. We might think that it's all ok
> > now, because we can see that our current implementation calls the
> > lower level function, but if that changed (perhaps accidently) then
> > we would never know that the higher level function is not fulfilling
> > its contract, because we have totally left this out of its contract.
> >
> > I hope this makes some sense ?
> > Sorry to have rambled on a bit !
> >
> > So, can anyone advise me at to how we really should be setting up our
> > contracts in this kind of situation ?
> > duplicate, or not ?
> >
> > thanks very much ! :)
> >
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...
<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
All good points, well stated.
Another important aspect of contracts is that they constitute a (verifiable) specification. No doubt when your coworkers hear "specification", the flinch a little but perhaps you can explain that good contracts in the code will free them of separate (unmaintainable) specfication chores (everybody loves a bargain). As teams grow and separate, contracts remain and serve to specify the interface between teams as much as between components. Most organizations will have different groups working on different layers (or components) and so having contracts at each layer and in each component provides a built-in mechanism for reducing inter-team management overhead. The upper-layer teams become clients (in real world terms) of the lower-layer teams and so the in-code contracts serve to specify and enforce the human-layer contracts, making for a much smoother relationship. The lower-layer teams can choose any implementation method they desire, as long as it fulfills their customer's (the upper-layer team's) defined requirements (the contracts).
Contracts' value as "finders" w/r/t implementation flaws is huge of course, but let's also remember their net effect on system complexity. A well balanced contract (as elegantly illustrated in Jim McKim's and Brian Henderson-Sellers's "Contracting - What's in it for the Supplier?") results in the minimal complexity. Your team might have bought into this notion already, but a gentle reminder every once in a while can't hurt.
It might also be helpful to note that the belief that a given contract is superfluous is seen by some (me) as irrefutable proof of "POOP" (procedure-oriented object programming). "I know that this is the sequence of instructions, so I need not do this again" is a sound observation in a truly procedural system (it's what allows us to build optimizers). The problem is that component systems are not procedural even if individual components are. Engineers love to criticize Marketing types every time they say "all you have to do is ...", but that seems to be exactly what engineers are saying when dimissing the need/value of contracts at every layer. Save the "all you gotta do is" for within the loop or function, but don't paint the whole system with the same brush.
As for the turn-off-later approach, it too can be layered to match your system architecture. If you arrange you layers into a cluster-like grouping, then the compile-time and run-time switches can be turned off at each layer as needed or desired.
Now that you have introduced DbC, you've opened up a world of possibilities for product and process improvement. DbC will in time allow you to streamline your operations and give back to your developers more high-quality time. They'll become more productive and more personally satisfied with their work (really). They won't believe this until they see it of course (none of us would).
Keep up the good work
R
==================================================
Roger F. Osmond
----------------------------------------
Amalasoft Corporation
273 Harwood Avenue
Littleton, MA 01460
> -------- Original Message --------
> Subject: [eiffel_software] Re: DbC question - duplicated contracts
> From: "colinlema" <clemahieu@...>
> Date: Sat, May 17, 2008 1:34 am
> To: eiffel_software@...
>
> It also might help to point out that contracts will not be in the
> system once finalized. Their purpose is for development for the
> reasons stated before. When the system is finalized the trust is
> established that the low levels will do their jobs correctly, not
> during development.
>
> --- In eiffel_software@..., "streborg" <streborg@...> wrote:
> >
> > Hi, I am trying to introduce DbC to our developers (albeit using
> > Java...one step at a time ! ;) ) ...and am finding that there is
> > resistance at a certain level, that applying it in what I think is a
> > rigorous manner is seen as needless, and going too far.
> >
> > A typical situation is when a function calls a "lower level" function
> > which does the "real work". It is thought that we are just
> > duplicating contracts needlessly.
> >
> > For example, we have various layers in our software - domain,
> > application, UI, data. At the application level, say, we have
> > a "store" function (which stores some kind of object to the
> > database). To achieve its goal, it calls a corresponding data
> > layer "store" function. The application layer store function
> > basically does some transforming of the object to an appropriate
> > format (from a DTO do a domain object), and then calls the data layer
> > store function.
> >
> > So, to my way of thinking, the contracts (just concentrating on
> > postconditions here) are quite straightforward. The application layer
> > store method will guarantee that the object gets stored. The data
> > layer store method pretty much also guarantees the same thing. (There
> > will be various differences too, as well as in the preconditions, eg,
> > dealing with the different formats).
> >
> > So, if we have similar postconditions at these 2 levels, it is seen
> > as pointlessly duplicating them.
> >
> > However, the way I see it is that is is perfectly ok to do this.
> > After all, they do in fact do similar things. Also, contracts are for
> > specifying WHAT is done, not HOW. So, for writing contracts, we
> > should be oblivious to how the function is fulfilling its
> > postconditions (in this case by calling the lower level store
> > function) and simply concentrate on WHAT should be true after the
> > function has done its job.
> >
> > Also, "duplicating" the postconditions is building up internal
> > consistency within the application.
> >
> > Colleagues are arguing that we should look at what the function is
> > doing, ie calling the lower level store function, and because it has
> > the postcondition that it will store the object, then we
> > should "trust" it to do its job, and not bother duplicating the
> > postcondition at the application layer.
> >
> > To me this totally goes against the idea that the contracts are
> > stating WHAT should be done, not HOW. We might think that it's all ok
> > now, because we can see that our current implementation calls the
> > lower level function, but if that changed (perhaps accidently) then
> > we would never know that the higher level function is not fulfilling
> > its contract, because we have totally left this out of its contract.
> >
> > I hope this makes some sense ?
> > Sorry to have rambled on a bit !
> >
> > So, can anyone advise me at to how we really should be setting up our
> > contracts in this kind of situation ?
> > duplicate, or not ?
> >
> > thanks very much ! :)
> >
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...
<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
« Return to Thread: DbC question - duplicated contracts
| Free Forum Powered by Nabble | Forum Help |