Air bags vs statistics
An airbag broke my arm. BDUF would have saved time. Test-first wasted effort. Should abandon these?In 2009 I was in a car accident. I was driving home from work, 2 blocks from home, when a car crossed in front of me, having just run a stop sign. I was unable to stop in time to avoid collision. But I did have time to jam my fist into the horn.
However, having my hand on the horn at the time of impact turned out to be rather dangerous. You see, the airbag is embedded in the steering column, where the horn is. So when the two cars struck, the airbag deployed and broke my arm.
So now I always disable the airbags whenever I’m driving, right?
No. Of course not.
We have some pretty solid evidence that, while sometimes airbags may cause an injury, such as mine, on the whole, airbags save lives.
And short of perfect fortune telling ability, to know which accidents would benefit from airbags, and which would be better without, we’re better off using airbags all the time. (And if we had such fortune-telling ability, I’m sure we’d just avoid those accidents entirely.)
Yet I often see people making this mistake in software. They get burned once by something, and therefore decide that thing is bad.
I heard this argument recently phrased something like:
Iterative design doesn’t work, because if we had spent more time planning this feature up front, it would have saved us time.
Yes, there will always be examples when a little planning up front, would have saved time. But on average, up-front planning wastes time, because our assumptions are usually (but not always) wrong.
Or maybe it’s:
Test-first development takes more time, and if we refactor or rewrite soon, that effort is wasted.
Putting aside the fact that I don’t believe test-first development does take more time, let’s accept the argument at face value. So sometimes you throw away the code you’ve tested. What about all the times you don’t throw that code away? To paraphrase a popular saying: “If you think testing your code is expensive, try not testing your code.”
The bottom line is: Many good practices are good because, on average, they produce better results. This doesn’t necissarily mean they always produce better results.