Why Is "Design by Contract" Not More Popular?

Coryoth writes "Design by Contract, writing pre- and post-conditions on functions, seemed like straightforward common sense to me. Such conditions, in the form of executable code, not only provide more exacting API documentation, but also provide a test harness. Having easy to write unit tests, that are automatically integrated into the inheritance hierarchy in OO languages, 'just made sense'. However, despite being available (to varying degrees of completeness) for many languages other than Eiffel, including Java, C++, Perl, Python, Ruby, Ada, and even Haskell and Ocaml, the concept has never gained significant traction, particularly in comparison to unit testing frameworks (which DbC complements nicely), and hype like 'Extreme Programming'. So why did Design by Contract fail to take off?"

Comments

Re:Management

[Anonymous Brave Guy]

People have a tendency to confuse bluster and arrogance with ability and experience.

They do, yet in my experience, these things are inversely correlated. This applies to all guidance/oversight roles, including business analysts, software architects, consultants, and indeed managers themselves. As I've commented here before, you can always identify a good leader by three characteristics:

• They can set a clear direction and convey this to others.
• They organise adequate resources and set realistic expectations.
• Having done the above, they get out of the way as much as possible.

The third one is usually the easiest way to identify morons. If you come across a leader in software development who places more value on reports and metrics so they can track things than they do on supporting the developers and test teams working for them, then you know you're dealing with an incompetent.

And yes, that does mean many leaders in software development organisations today are incompetent. That's why the genuinely good people are worth so much.

Re:no bang for your buck

[Tablizer]

In a phrase, the niche is professional coders, rather than hack-a-day cowboys.

I think you are being naive. In the real world they often want as many features as possible with the smallest staff possible. This means that things like formal testing are glossed over. It is an art-form to deliver tons of features on the cheap. Of course, it depends on the nature of the business. If it is the Space Shuttle or medical equipment, then you better spend the extra money or you will get sued up the wazoo. An intranet app will also have a different Q.A. profile than packaged software, since the ratio of users per line-of-code is different. The US's comparative advantage is being nimble, not formal, such that the beurocracy for Q.A. is often bypassed to keep up. If the idea becomes a commodity idea such that requirements and thus testing it is easy and stable, development gets shipped overseas.