Going full circle with TDD

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

This entry was posted in TDD. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Kyle Baley

    @mattcalla

    Ya, that’s a tough one, mainly because any code you right using TDD can just as easily be written without it. If you look at only the final product, it’s easy to say “Pfft, I could have written that on my own.” It’s the process of getting there that makes it worthwhile. Closing the feedback loop and getting more maintainable code easier. Jean-Paul Boodhoo had some good sessions on it at dnrTV but I think it really needs to be taught in a two-way manner (like he does in his boot camp).

  • http://mattcalla.com mattcalla

    I’m going through this same situation right now of trying to explain/demostrate/prove how useful TDD can be at producing higher quality end results. I’d love to know if you have found any particular code example or explanation that works best at showing TDD in all its glory?

  • Kyle Baley

    @Dave B

    Less code is not the goal. Maintainable code is. Less code is often a side effect but not always. In fact, many refactorings (eg. Extract to Method) result in more code.

    But having said that, I’m no longer convinced TDD, in and of itself, results in “more code”. It certainly encourages you to follow the Single Responsibility Principle which will lead to more code than if you didn’t. So it’s a side effect of the design principle, not the methodology. I would argue that if you *didn’t* use TDD, but still followed good design principles, you would end up with the same (or very similar) code that would with TDD.

    But for me, TDD can take me there in a much more intuitive fashion.

  • http://devlicio.us/blogs/derik_whittaker/default.aspx Derik Whittaker

    @Dave B

    Yes the goal is to write less code. But a bigger goal should be to write more stable and tested code. Without tests you have no way of knowing your ‘less’ code actually works today, tomorrow or any point in the future.

  • Tom

    I’d be interested as well;

    I head my aha moment a couple of days ago when reading Karl Seguin’s free Foundation’s of Programming book.
    The thing that struck me was the combination of Separation of concerns, Rhino mocks and structuremap for injecting the mock interface. It all made sence all of a sudden. Design your classes close to the rules of SRP/OCP; test them with rhino mocks; easy!

  • Dave B

    I am still not convinced (at least not for the whole enchilada). Is not the goal to write Less code and is it not true that less code easier to maintain? I do like the idea of running unit tests at build and the continuous integration concepts.

  • http://sleeplessmonkey.com Steve Evans

    I completely agree with you that learning TDD (or any of the Agile practices for that matter) is difficult without a mentor approach. I’ve been trying to teach myself TDD for the past year now (primarily because a year and a half long data conversion project was not fun…), but I’ve been struggling on where to even start. I’ve read up so much on it but still feel like I’m missing something. I have a feeling when I get the “AH HA!” moment the light bulb going off will blind somebody.

    Anyways, keep us posted if you plan on following up with the Skype idea. It seems like a lot of the companies around here that practice TDD/Agile techniques only want to teach others the techniques if they’re just starting out in a lowly Dev I type position.

  • John Miller

    You pretty much summed up exactly what I’m going through at the moment. I work for a company with around two dozen developers and we’ve been running fairly smoothly with out TDD, but I’m really anxious to give it a try on our next large project.

    Count me in!

  • http://davesquared.blogspot.com David Tchepak

    I’d be in for a Skype coding session :)

  • http://dotnet.kapenilattex.com Jon Limjap

    Well whenever that skype thing is I’d like to join in (hopefully the time zone differences won’t mean much).