Every once in a while I read something like this:

Yeah, [TDD|BDD|ATDD] is great. But how do you convince [your manager|your employer|your colleagues] to get the time to do it?

In the past week I decided that I need something to point folks to when this questions comes up again. So, here it is.

TDD does not work

First of all, I think it helps to apply a lesson that I learned years ago as a swimming trainer. I had several exercises in my repertoire that were a bit unusual, and at times hard to do. These included variations of swimming strokes in unusual positions.

Every now and then when I gave out one of the exercises to the kids, some or all of them were complaining: “this doesn’t work”, “I can’t swim like that”, etc.

What the kids didn’t know was that I had learned to try out these exercises on my own first to get a grasp of how difficult they were. Thereby I also knew that they were possible to do. Over time, I realized that “this doesn’t work” could be easily translated to “I don’t know how I can make this work”, and tada, let me see how I can help you with that.

Today, I apply the same lesson to TDD. Whenever someone tells me that TDD does not work in his code base, well, I make the mental translation to “I don’t know how TDD works on my code base”, and off we go.

My boss won’t let me

Yeah, right. Here’s a hard message for you: are you telling your carpenter how to hold his hammer? Are you telling your plumber how to use the pipe wrench? Are you telling your car mechanic when to replace the oil filter?

Seriously, why is your boss, your project manager or whatever excuse you have not use TDD telling you how to do your job? I thought you are a highly educated knowledge worker. If you are convinced about the effectiveness of TDD, then no boss or project manager should be telling you how to do your job.

Oh, sorry, there actually is one case when this might be appropriate for your boss to tell you. When you are not able to deliver working software that adheres to the business goals using TDD.

But remember: that’s feedback about how you use TDD, not about how bad your boss or project manager may be. So, better practice applying TDD and helpful design practices to be able to better serve the projects you are working on.

TDD does not work with my [language|framework|etc.]

Sure. That’s an easy excuse. Yeah, those darn language or framework programmers weren’t helpful. That’s how it’s going to work.

Uhm, wait a minute. What do you think how old TDD actually is? A thing from the Smalltalk community? It turns out, not quite right.

A while ago, Arialdo Martini wrote a blog entry on how old TDD actually is. Click that link, go there. Make sure, to read it up until the end. I’ll wait here with my rant.

Surprised? So was I – to some extent. Besides the fact that things like TDD have been mentioned in papers and publication by Dijkstra, and the first NATO conferences, TDD actually is way older than that.

Also note what Jerry Weinberg says in this interview with Michael Bolton about TDD:

Michael: […] I’ve learned about both from conversations that I’ve had with you and other smart people. I remember once that Joshua Kerievsky asked you about why and how you tested in the old days—and I remember you telling Josh that you were compelled to test because the equipment was so unreliable. Computers don’t break down as they used to, so what’s the motivation for unit testing and test-first programming today?

Jerry: We didn’t call those things by those names back then, but if you look at my first book (Computer Programming Fundamentals, Leeds & Weinberg, first edition 1961 —MB) and many others since, you’ll see that was always the way we thought was the only logical way to do things. I learned it from Bernie Dimsdale, who learned it from von Neumann.

When I started in computing, I had nobody to teach me programming, so I read the manuals and taught myself. I thought I was pretty good, then I ran into Bernie (in 1957), who showed me how the really smart people did things. My ego was a bit shocked at first, but then I figured out that if von Neumann did things this way, I should.

John von Neumann was a lot smarter than I’ll ever be, or than most people will ever be, but all that means is that we should learn from him.[…]

So, the next time your boss approaches you asking to leave out those unit tests or stop that TDD thing, tell them the story on how Jerry Weinberg learned it from Bernie Dimsdale who learned it from John von Neumann. Then ask them that you don’t consider yourself smarter than John von Neumann.

Oh, and besides, even though some of our hardware became more reliable, most of our software hasn’t. When answering the question why we ever gave up something that John von Neumann taught us, I wouldn’t accept that excuse either.

What if all of that doesn’t work?

A couple of years back, I attended a Code Retreat session in Bielefeld. We worked all day using TDD, in six consecutive sessions, always deleting our code at the end, since we strived to learn about TDD, not to come up with a beautiful solution to a long solved problem.

At the end of the day, we held a quick retrospective. Everyone shared what they learned that day, and what they would be doing differently back at work next Monday. One guy stepped forward and said that he would change jobs on Monday since he never would be able to use TDD at his current job. Now, after he experienced it, he never wanted to do anything else.

That said, of course the “change your organization or change your organization” phrase also applies to TDD. If you are convinced about the approach, and never want to do anything else, and your environment currently doesn’t support it, well, move ahead.

In case you want to learn more, attend one of the events for the Global Day of Code Retreat in two weeks. Since I always learn one little thing at each of these events, I will be attending the one in Bielefeld, Germany.