Mike Clark

I had a great turnout for my "Test-Driven Development With JUnit" talk this weekend at the No Fluff, Just Stuff symposium in sunny Seattle, despite going up against Glenn's stacked deck at the same time. ;-)

It's always rewarding to get stellar reviews on a talk, but this time I got a few extra goodies. A number of attendees used the word "convincing" on their evaluation form. Now it's not unusual that folks give TDD a whirl after listening to me extol its virtues. After all, with all those green bars flashing by you can't help but want to pop one yourself. But this is the first time I've received nearly-unanimous reports that the talk was convincing.

So on the plane ride home when I was sifting through the evals, I started thinking about what was different this time. I'm always looking for opportunities to use feedback as a resource. The results of every talk I give get piped into the next talk. And I've given this talk about a dozen times, so it's been... err... mercilessly refactored.

Earlier in the week I had taught a course on TDD using JUnit to a bright team of QA and development folks. Their enthusiasm no doubt kept me wired through the weekend. I'm very much looking forward to watching JUnit and TDD take root on their project. Perhaps that enjoyable experience got me started on the right foot.

But in general I'm just really passionate about TDD. When I'm up there talking, I'm not shy about telling you how insecure and unproductive I am without it. I guess I've never been too shy about sharing my failures. What do I have to hide? Indeed, the more I hide the less I learn. Example: Oh sure, I used to write unit tests after my code seemed to be working, but I loathed doing it and my tests weren't all that good. I was always hurriedly testing in hopes of getting back to the creative process of writing code. (Maybe I'm a bad programmer, methinks.) Only now have I discovered that writing tests first is part of the creativity. Better yet, I'm writing better tests because I'm actually enjoying the design benefits and the freedom the tests afford me to change code with impunity.

And I've been studying and practicing object-oriented design and patterns for over a decade now. I've got all the books and t-shirts to prove it. But when I'm honest with myself I know that most of that time I was really frustrated. Too often my beautiful UML designs turned ugly when I tried to codify them. (Maybe I'm a bad designer, methinks.) It's a bit hard to swallow, but I think I've learned more about OO in the last two years since picking up TDD than I did in all the years previous. But more importantly, I'm having fun with it because my designs are actually working. They're simpler, yet they still exhibit the qualities we associate with a good design: high cohesion and low coupling.

So here's my advice if you're trying to convince your team to use TDD: Just honestly tell them how it's working for you. And then stop talking. Don't worry about trying to convince them that TDD should also work for them. Yeah, I know that the books say it should and x number of programmers can't be wrong, but forget all that. Our industry is already polluted with tools and techniques that were supposed to work. Folks have to decide for themselves to try TDD and then shape it into their own technique -- based on their context. You can't do that for them, and they'll hate you all the more if you try. And if listening to a so-called "OO expert" talk about his frailties helps, I'd love an opportunity to tell them, and show them, how TDD is working for me.