I was teaching a class that included a chapter on testing this week. I had added a section on design by contract and decided to look into what is available in the .NET space. I knew about Eiffel for .NET and some time ago looked into sharp#. I had to read up on the language specification of spec# so that I could add a reasonable contract for my examples.
I was very impressed with spec# and the static verification that Boogie provides.
I am even more excited that .NET 4 will provide a generic specification language. Maybe it is finally time for DbC to get out of academia and into mainstream?
For 15 years now, I’ve been teaching DbC at every occasion I could. I’ve long been convinced that it has significant positive impact on software quality. I’ve even had the chance to witness it close up the few times I’ve had success at convincing software organizations of DbC’s advantages.
So, why have DbC taken so long to catch on (assuming .NET 4 elevates it to main stream)? I have a few theories…
The first theory is that the DbC community seems to be constantly trying to show examples that are intellectually challenging to show how tight they can create a contract. These contracts become so complex that the specifications are significantly more complex than the algorithm required for the implementation. For a practitioner reading these specs, the concepts must look absolutely horrifying!
The other theory is that DbC often is presented in a confrontational style. I’m guilty of this too. I used to love to start my DbC presentations with statements like “I’ll show you something that will make you never write defensive code again”. Or I may focus on the fact that it is OK to crash and burn when preconditions are not met. Even though those statements may be theoretically correct, they will scare away practitioners. I promise I will never do that again.
No wonder, the community is apprehensive. Even academic giants like D. Firesmith end up writing an article showing how Defensive Programming is superior to DbC. Scary!!!
How about we as educators start focusing on the simple things that DbC can do… and assume that the contracts will be checked at runtime and that catching them will not make the system crash and burn… We can introduce the other factors later… when the concepts mature.
The statistics are greatly in our favor. Check the numbers from Lockheed’s experience from the C130J (Hercules II) project where the software quality improved by a factor 10 and productivity by factor 4… Those are strong numbers