“We were doing TDD just like we’re supposed to, but at some point it started hurting, so we not only quit, we told everyone else on the interwebs that TDD doesn’t work.”I met Kent Beck after a couple of years reading and writing around him, at the first ObjectMentor Extreme Programming (XP) Immersion, a wonderful week I’ll never forget, where I met so many awesome geeks and coaches. (Kent Beck, Mike Feathers, James Grenning, Bob Martin, Ron Jeffries, Martin Fowler, and more! You get the idea it was a special week?)
And Beck, answering a question, told the old Smith & Dale joke:
SMITH: Doctor, it hurts when I do this.
DALE: Don’t do that.
(The visuals include a funny wagging arm movement by Smith.)
One might interpret it as saying “TDD hurts me, so I won’t do TDD,” but that’s actually the wrong way to interpret the joke.
You see, TDD works for some of us. And it works very well.
But it’s really important that you hear what I’m not saying.
I’m not saying that you didn’t – or aren’t – feeling pain. I’m not saying you weren’t – or aren’t – trying. I’m not saying TDD works for us because we’re smart and you’re stupid.
What I’m saying is that you are not responding to the pain you’re feeling in the TDD way.
I don’t mean that it’s not painful in the sense of “you’ll just feel a little pinch”. I mean it’s not painful at all, really.
So when we feel pain while doing TDD, something is going wrong.
The somethings that could go wrong are exactly three:
The key to successful legacy work is to become a master of extraction refactorings. Before you TDD a change, extract the change site so that it is optimal for microtesting.
When you can’t write a real microtest because of the location or accessibility or complexity, either move, extract, or simplify the code via refactorings. It’s not hard, but it’s tedious as hell, and it takes a certain boldness.
This will help. It will ease your immediate TDD pain, and it will – very gradually – lift you out of legacy work altogether.
But yeah. Legacy hurts for as long as it’s legacy, and there are not two ways about it.
But there are some situations where learning hurts. Most of these are situations where you have to learn something while 7 people are shouting at you that if we don’t fix this we will simply all die. Let me tell you, that’s gonna hurt no matter what you do. Suggesting, of course, that we teach people not to do that.
There’s another time when it hurts. It hurts to learn when your current goal is too far over your head.
I have worked from time to time with folks with weak TDD, weak confidence, and weak knowledge of a language or a domain. That’s a painful combination.
If you are stuck at the incantation stage in a language, where you’re just barely avoiding syntax errors, and the fundamentals of the language are not yet within your grasp, it’s sore tempting to drop TDD altogether and just focus on typing the magic in correctly.
But it’s contraindicated. The reason TDD is a great design technique is because it organizes the design. That organization, plus simple extended exposure, is going to be the thing that ratchets your knowledge up most rapidly. Abandoning TDD will slow down your learning, not speed up.
I have a strong belief that code pain is the main reason people leave TDD behind.
And here’s what they’re doing wrong: gritting their teeth and trying to play through it.
That’s not the TDD way. In TDD, when we feel pain we change the code until we don’t feel it anymore. And we add what we’ve learned to our daily codesense.
Codesense isn’t one trick, it’s a thousand. And it isn’t an algorithm. Codesense comes into play at large scales and at smalls. But it all comes from feeling pain and resolving not to feel it any more.
Coming soon to a blog near you: live-action codesense examples, where pain leads to refactoring leads to new design.