A couple of years ago, I had lunch with JP. It was before TDD had clicked for me and I was still very much a skeptic. As always, JP was passionate but not forceful in his explanation of it but by the end of the lunch, I still wasn't sold. So much so that I wrote a nice little write-up that, upon re-reading, is akin to looking at pictures of my choice of clothing in the 80s. (What can I say? Corduroy worked for me.)

So it is with some bemusement that I reflect on almost the exact same conversation I had with another young developer three days ago, except that I played the part of JP and he played the part of the skeptic. I recognized each and every argument he posed because I made them myself at one point: It takes too long. What's the difference whether I test first or test after? There's too much code. It's safe and warm and fuzzy in my world and I won't have you telling me otherwise.

The argument wasn't all that heated because we're both Canadian. But in the end, the only real argument that stuck with him is the same one that stuck with me originally: it works for me. I've been doing it for a while now and I like the results I get with it. Maybe I can't quantify the specific time and/or cost savings over time but I can tell you, it "feels" right. I like looking at the software I build with it. I like going back to it to add features. There's a much smaller learning curve when reviewing it after a few months.

Maybe I can get that same feeling just by adopting a few decent development practices rather than a full-on design methodology. That may be so, though it seems to me that TDD allows you to adopt such practices a lot more naturally. So that you aren't forcing yourself to learn them. Rather, you learn TDD and other design principles seem that much clearer.

Of course, TDD isn't exactly a walk in the park itself and it sure does help if you can learn alongside someone who has done it. And even now, I'd rank myself only about a 4 or 5 out of 10 on the "TDD Afficianado" scale (though if a recruiter asks, the answer is always 7). Past the book-learning phase but still not practised enough that I could, say, teach a course on it.

Which I think is part of the barrier to entry. It's hard (for me, at least) to learn on one's own without some real-world work backing it up when the class/seminar is over. Often, there is a sense of hopelessness anyway at having your eyes opened to a new world, then returning to your regular job at Niagra Inc.

At one point, I had some vague plan to do an online Skype thing with whomever wanted to join to talk about something like this. Not to teach but to share my findings and see if anyone else would either learn from it or enhance my knowledge of it. I do hope I have the wherewithal to follow through on it because I do so love the idea. Kind of a real-time version of Derik's www.dimecasts.net site (which continues to be awesome if you haven't checked it out).

Anyway, I'm not entirely sure where I'm going here. Just liked the symmetry of the two conversations, I guess but I'll stop now. Let me know if you'd be interested in a Skype coding session, possibly sometime in September when I've fled this foreign corporate cowboy world again.

Kyle the Circuitous