The right kind of lazy

I consider test-driven development (TDD) to be a basic software development technique. I’ve used it in a wide range of circumstances for different types of applications in different domains based on different languages and tools. I coach people in using the technique, I run workshops at conferences on it, and I offer a two-day training class on it.

My only regret is that I didn’t learn about TDD earlier in my career. All those years doing things the hard way…time lost forever. Oh, well.

I use TDD and I like it, but I never try to “convince” anyone that they should use it, or even that it works well. I never suggest that TDD is a “goal” for an individual or for a team. TDD might help you achieve some other goal, but it isn’t a goal in itself. It’s just a technique.

And, let’s face it, nearly all the code in production today, worldwide, was developed without TDD. Nearly all the code under development right now is being developed without TDD. Clearly, programmers can get along without it.

Some people insist that TDD is nothing but a crutch for stupid programmers. As far as I know, they’re right. Being less intelligent than they, how would I be able to tell if they were wrong? This is another reason not to get into debates about it.

A programmer’s job is to deliver good code: Code that can be proven correct in a repeatable fashion by anyone at any time, that is well-factored, and that doesn’t introduce any regressions. How they do it is really up to them. If they can do it without the aid of any rigorous software development techniques, more power to them.

When people try to bait me into a debate about TDD, I just smile, shrug, and say, “OK.” Maybe they’re really smarter than I, and they can just type out a perfect program on the first go. Must be nice. Or maybe they just don’t mind creating extra work for themselves. It’s all good. There’s nothing to debate.

Often, a person really, really wants to get into a debate about it. Eventually, they get around to asking a question of the general form, “Why do you, personally, use TDD?”

Now it isn’t a debate, it’s just a question. That’s better. I tell them that I use TDD because I’m fundamentally lazy. I don’t want to do my work in a way that creates extra work. I call this sort of extra work induced work, a term I learned from Alan Shalloway. I don’t want to induce unnecessary work for myself or for others. Chasing down bugs, cleaning up technical debt, and re-doing routines that I thought were already finished are not my idea of fun. I’m embarrassed when I induce work for the people who have to test, integrate, modify, or use my code.

I just want to complete the solution properly and be done with it, so I can play video games, read, play music, or take my wife out on a date. I like to sleep at night, rather than answering the phone to deal with production support issues. So I choose methods that tend to help me get the job done without generating induced work, whether I’m doing analysis, design, programming, or testing.

Often, the person will respond by saying that they aren’t convinced TDD actually helps people deliver good solutions. I just smile, shrug, and say, “OK.” Work however you wish to work. It’s your time to spend. It’s your life. Then we move on to some other subject, or we proceed with whatever work we have at hand.

Usually, people who are skeptical about TDD are also curious about it. If they weren’t curious, they wouldn’t bother to express skepticism; they would just ignore the subject. They want to know if someone can make a compelling argument that will inspire them to give it a try, but they don’t want to waste their time trying it for themselves just in case it doesn’t prove useful (even though that wouldn’t take very much of their time, and would be a very easy way for them to satisfy their own curiosity).

Of course, they have a well-rehearsed answer ready for any argument a person might make, and some of them are quite eager to show how cleverly they can put the lie to TDD. So, when I fail to respond argumentatively, they come back for more. They are, after all, curious, even if they don’t say so.

Eventually they realize my attitude is that they are perfectly free to make their own lives harder than necessary, if that’s what they choose to do. As for me, I’m far, far too lazy not to test-drive my code. They realize that I don’t even consider this a worthwhile topic of discussion. All I ever do when they try to start a debate about it is smile, shrug, and say, “OK.”

You might think that would be the end of it, and we would just go our separate ways as far as programming technique is concerned. You might assume they would reckon, “That Dave guy has no compelling argument in favor of TDD. It must be a crock.” But that’s not what tends to happen.

As they continue to work with me, they begin to understand that I really am pretty damned lazy by nature, so if this TDD thing actually enables me to function on the job, there might be something to it, after all. Still skeptical and now even more curious, the person comes back around again, this time not to debate but to ask me to show them how to do it. So I show them.

I haven’t had anyone dislike it, so far.

But TDD isn’t for everyone. There are many who, to this day, are still searching for academic studies that “prove” (to their satisfaction) that TDD “works.” They search, that is, when they aren’t too busy chasing down bugs, cleaning up technical debt, re-doing routines they thought were already finished, or explaining themselves to the people who have to test, integrate, modify, or use their code.

It’s a good thing they aren’t lazy.