Sunday, January 22, 2006
A Better Way of Selling DbC?
I was reading a draft writeup on Eiffel's Design by Contract, and I realized that the common approach for describing DbC is as a mechanism for finding bugs in the code you write.
Now how many people are willing to admit that they write buggy code? How many people have reached DbC in an exposition on Eiffel, and looked at the example stack trace, and had this visceral reaction: "this is wrong because when it happens it will be someone else's fault, not mine, and I don't want to waste my time finding someone else's bugs, because way deep down in the bowels of my psyche, I Know I Write Perfect Code"?
I don't think people would consciously make a decision to not use Eiffel because of this, but like strong typing and Single Entry/Single Exit, a lot of people are going to look at this and think that it's not for them, it's too strong a cup of tea, or its tea and not beer, and because they Write Perfect Code, so they deserve to get weak beer instead of strong tea.
If you walked into a roomful of your peers who've found Eiffel on their own (I'm lucky enough to be able to do this in the Real World; others might have to use a virtual room of some sort) you'll find that a lot of these people have grown out of the notion that they Write Perfect Code and have been so frustrated with other languages that they casted about and found Eiffel in their nets.
Not many people have the maturity to grow out of the illusion that they Write Perfect Code, but they do know that no one else does! When the program crashes, the thinking goes that "my code is perfect, I know the bug is in [insert name here]'s code."
So perhaps a better way of pitching DbC is to say that it finds the bugs other people write, when they use your code! Now the subconscious thinking is, "Ha! When the application crashes on my contract, everyone will know it's [insert name here]'s fault, and not mine, because in my Perfect Code, I have written Perfect Contracts!"
We can make a similar argument in support of other strong measures like Single Entry/Single Exit. In the fall of 2005 one of the Eiffel mailing lists had a nice flamewar over this, and in the end I don't think anyone was convinced one way or another. But I did not try the argument, "Hey you may be smart enough to understand a multiply-nested loop with the propositions scattered all about and about five ways of getting in and out of the innermost loop, but there's no way [insert name here] down the hall will be able to maintain this code and not mess it up completely." Or put another way, you may be clever enough to write and maintain Perfect Code that is that complex, but a lot of the people who will follow you into the code, or use it, may not be, or may not have the time to become that clever.
And unlike most other languages, Eiffel is just as much about readability and maintainability as it is about anything else.
Now how many people are willing to admit that they write buggy code? How many people have reached DbC in an exposition on Eiffel, and looked at the example stack trace, and had this visceral reaction: "this is wrong because when it happens it will be someone else's fault, not mine, and I don't want to waste my time finding someone else's bugs, because way deep down in the bowels of my psyche, I Know I Write Perfect Code"?
I don't think people would consciously make a decision to not use Eiffel because of this, but like strong typing and Single Entry/Single Exit, a lot of people are going to look at this and think that it's not for them, it's too strong a cup of tea, or its tea and not beer, and because they Write Perfect Code, so they deserve to get weak beer instead of strong tea.
If you walked into a roomful of your peers who've found Eiffel on their own (I'm lucky enough to be able to do this in the Real World; others might have to use a virtual room of some sort) you'll find that a lot of these people have grown out of the notion that they Write Perfect Code and have been so frustrated with other languages that they casted about and found Eiffel in their nets.
Not many people have the maturity to grow out of the illusion that they Write Perfect Code, but they do know that no one else does! When the program crashes, the thinking goes that "my code is perfect, I know the bug is in [insert name here]'s code."
So perhaps a better way of pitching DbC is to say that it finds the bugs other people write, when they use your code! Now the subconscious thinking is, "Ha! When the application crashes on my contract, everyone will know it's [insert name here]'s fault, and not mine, because in my Perfect Code, I have written Perfect Contracts!"
We can make a similar argument in support of other strong measures like Single Entry/Single Exit. In the fall of 2005 one of the Eiffel mailing lists had a nice flamewar over this, and in the end I don't think anyone was convinced one way or another. But I did not try the argument, "Hey you may be smart enough to understand a multiply-nested loop with the propositions scattered all about and about five ways of getting in and out of the innermost loop, but there's no way [insert name here] down the hall will be able to maintain this code and not mess it up completely." Or put another way, you may be clever enough to write and maintain Perfect Code that is that complex, but a lot of the people who will follow you into the code, or use it, may not be, or may not have the time to become that clever.
And unlike most other languages, Eiffel is just as much about readability and maintainability as it is about anything else.
posted by greg c @ 18:18 
Comments:
<< Home
I have no delusions about my ability to write perfect code. This is exactly why I use Eiffel; DbC has saved me an immense amount of debugging time.
Of course, sometimes I write bad contracts, too. But that's another story.
Of course, sometimes I write bad contracts, too. But that's another story.
We find that designers and programmers actually make about the same number of errors. I.e., when analysing software with formal contracts, about half of the bugs are in the code and half are in the contracts. Writing good contracts is actually harder than writing good code for nearly all programmers I know.
We try to find people who are good at declarative thinking and abstraction to do the contract writing and others that are good at operational and concrete thinking to do the coding.
Likewise, you like to find people who are anal, analytical, and like to challenge others to perform Q/A (e.g., design, write, and generate unit tests).
Post a Comment
We try to find people who are good at declarative thinking and abstraction to do the contract writing and others that are good at operational and concrete thinking to do the coding.
Likewise, you like to find people who are anal, analytical, and like to challenge others to perform Q/A (e.g., design, write, and generate unit tests).
<< Home
