Why Design By Contract Is Not Popular
Arg. Design by Contract has been around for a long time, however it has never gained the popularity of other programming paradigms. Although I don’t completely understand why since it supplements unit testing so well and increases overall software quality, I suppose that I can fathom some guesses.
The first is because of suits (which is what we call THOSE management types on this blog[this excludes some management types that I like]). Suits don’t like DbC. Suits don’t DbC because it is something that requires very little participation on their end, and therefore they have little insight into the overall process. Since suits tend to be the ones that are either directly responsible for project invocation, tend to be the overall project sponsor, they are not fans when they can’t have a direct role in the software development process. Along the same lines, suits tend to not come from a programming background themselves, or there programming background is so fricking antiquated that it is completely inapplicable, therefore, DbC tends to shoot over their heads. With suits to, cost is king, and DbC, if being adapted, will cost more time and money. When you tell suits you are going to take an extra ten minutes to develop something, here is how the conversation will generally go:
[developer] I am going to rethink my development approach. I am going to use some DbC principles so that my methods have pre-conditions and post-conditions. This will make it easier to write unit tests since it will basically build up a test harness for me to use.
[suit] Whatever. how much longer will it take.
[developer] I would be estimating, but not more than a couple hours
(silence, the developer can tell this is going over like a fart in church)
[suit] Does the application currently work?
[developer] Sure, but it will increase the reliability of the software, so might be important to consider.
[suit] But it works right now doesn’t it?
[developer] Working doesn’t equate to reliability or robustness.
[suit] If it works, you should begin to work on the next requirement.
[developer] (arms raised) fine!
So that is the first reason that I think DbC has never caught on, even though it is just NATURAL.
Secondly, I don’t think people find in interesting, and most people doing SharePoint development just don’t CARE. And clients don’t CARE. It’s the same reason I think outsourcing took off so fricking amazing (this is a loose statement). People are willing to sacrifice quality of software for time and money. It’s not like other products since it is rare that the person that the software is being delivered to actually looks under the hood, and says, “Hey, what!?!?!?”. If it runs, it runs. If it breaks, oh well, even though it might cost more to fix the application than it would have been to spend some more time on it in the first place.
Thirdly, people don’t realize that you can do Contract Driven Design (CDD) with TDD. You know, this is possible.
Fourthly, people confuse unit testing with DbC. They may look similar, but they are NOT the same. CDD is firstly automated, since random data can be directly passed in and the specified contracts act as the test harness. This helps you find software bugs that you might not otherwise find in your code. To a larger extend, CDD couples with TDD (as described in the above gripe) in the sense that when you run your unit tests on code your contract constraints will be taken into consideration.
Lastly, since I am tired of writing about this most clients could giving a shit about API documentation. Why? I don’t know, but they really couldn’t. DbC as it builds your contracts into your API documentation (which generally is automated) greatly enhances the readability of your code as it is handed from developer to developer.
Ugh, I’m done writing about this.
< / rant >