TDD & The Lump Of Coding Fallacy

Hey, it’s GeePaw, and if you’re just starting to look at TDD, refactoring, the modern technical synthesis, we need to start with a couple of minutes about the Lump Of Coding fallacy.

You’re a working geek: you spend your days coding for money to add value to your company. And one day some random schmoe like me comes up to you and says, hey friend you really ought to try TDD, because that value that you’re adding, you could have added even faster if you used TDD. So, you check it out, because sometimes random schmoes actually have a clue, and you see pretty quickly that TDD means making lots of automated tests against your code. So what do you do?

Well, you back away slowly and you casually slide your hand into your pocket to get that little reassuring grip on your pepper spray, just in case.

Why is that? Well, it’s pretty simple really.

Look, you say to me, I already spent all day rolling code to add value. But if I do TDD, I do automated tests, and try to keep up with me here, doing automated tests is also rolling code.

So, if I adopt TDD, I suppose you think I’ll just spend all night coding the tests that cover the value I spend all day adding. Look random schmo, in the immortal words of Sweet Brown Wilkins,

“Ain’t nobody got time for that.”

OK. OK, my random schmo response to this is to suggest that your analysis is off. And specifically, that it suffers from what we call the lump of coding fallacy. You think of what you do all day as a single behavior, coding. A large undifferentiated lump of work. And you think that TDD means adding to that one lump of coding a whole different equally large lump in order to make the test.

Three Things We Do During A Coding Day

Here’s the thing, I don’t think what you do all day is a single behavior. I think it’s made up of several different behaviors. Let’s take a look.

  • One thing we do, we actually program the computer, and there’s two parts to that. There’s actually changing the source and then there is what we call designing, which is imagining forward how we’re about to change the source. That’s programming the computer. For many of us, it’s the best part of our day.
  • Next, we study. It’s not possible to change the source without knowing something about it. And the studying is how we know something about it. Again, there’s a couple of different parts. We scan source, which is flickering quickly from place to place. And then we read source, which is far more intense. It’s more line by line, a deep analysis of what’s really going on in the code. So that’s study.
  • The third thing we do during a coding day is what we call GAK activity. GAK is an acronym. It means geek at keyboard. And what it means is, running the program in order to accomplish some end or another. In GAK inspection, we’re running the program to see how it works right now. In GAK testing on the other hand, we’re running the program again, but this time to see whether some source change that we just made had the desired effect. And of course, there’s always GAK debugging, where we’re running the program, this time in debug mode, or print statements, or whatever, to see why that source change did not have the desired effect.

Two Points For Later

Now, before we go any further, I want to make sure you know two key aspects of the TDD world. First, when you’ve adopted TDD every source file really becomes a pair of files. One holds the source code we ship, and the other holds the source code for the microtests. And we use both of these files all the time, because they both offer us a great deal of information. That testing code forms a kind of scaffolding around the shipping code and we’re going to take advantage of that.

Second, TDD uses very small, very fast tests called microtests, and it runs them separately from running your entire application. The reason we can get away with testing only parts of the app, is because what matters most about our work is the branching logic that’s in it. And that’s the part we test most heavily using microtests. We run them in a separate app for speed, selectability, and ease of use.

So, take those two points and set them aside. They’re going to become important here in a minute. Hold onto them.

The Proportions Of The Three Activities

OK, let’s go back to our three activities. So, take these three things together, changing codes, studying code, and GAK activity, and you see there isn’t just one solid lump called coding. There’s all these activities. Of course, they’re totally intermingled throughout the day. And that’s why we think of it as a big lump. The truth is, they actually take up very different proportions of our programming day.

Programming the computer, the best part of the day, is often the very smallest part. The GAK activity, much of which is just waiting around for things to run, or clicking through screens and typing in data in order to get to the part where you wanted to see something, that is the largest part of the day by quite a bit. And studying, the scanning and the reading, well, it’s somewhere in the middle. So those are your basic proportions.

When TDD tells you that writing automated tests will make your life better, the lump of coding analysis of the idea is both right and wrong. Lets grow this picture a little bit. We’ll call what we’ve got now before TDD, and then I’m going to disappear, and we’ll put after TDD over on the right.

The After Picture

The lump of coding fallacy is absolutely right about one thing, automated tests are more code that has to be written. Somewhere between half again as much and twice as much as you write now. Let’s say that part of our day doubles. On the other hand, the lump of coding fallacy is totally wrong about the rest of the picture.

First, study time will go down after TDD. It’s not that we have to study any less code in the after picture than in the before. Rather, it’s that studying the same amount of code gets faster. Why? Because those twin files we talked about, one with shipping code and one with testing code, it’s almost like the test code forms a kind of Cliff’s Notes for the shipping code. A scaffolding that makes it easier for us to study, and this makes it far easier to tell what’s going on. This will cut our code study time in about half.

Finally, we come to the GAK time, and this is the big payoff. TDD reduces the amount of time you spend in GAK by 80% or 90%. Because TDD tests run in that special tool kit. They’re fast. They don’t fire up your application. They don’t depend on things like logins, or database permissions, or waiting around for the web to load. They are built to be fast, small, and grouped into convenient suites. Nothing completely eliminates the need for GAK work, but TDD slashes the amount of time you spend GAK-ing during the course of the workday.

So, when we look at the left and the right, from before TDD to after it, you can see it for yourself. We write more code, automated tests. And far from losing our productivity, we actually gain it. All this takes is for you to look past that single lump of coding fallacy.

GeePaw Advises

OK, it’s time for my advice. The first advice is the same advice I always give. Notice things. In your next full working day, notice how much time you spend in the three behaviors, actual programming, code study, and various GAK activities. Once you see it yourself, you might want to consider making some changes.

The second thing, well, TDD doesn’t come in a day. It takes some lessons and some practice. There’s a lot of course material out there, including mine. Watch some videos. Read a little, and really try the various exercises. Start with some toy code. Almost anything will do. Then find a small problem in your day job that has few or no dependencies on other classes. Do this two or three times. And again, notice what happens. If you like the result, well, at that point, you’re ready to get serious about TDD. And then, well, we can take it from there.

So, I’m GeePaw.

Drop that Lump Of Coding fallacy,

and I’m done!

Coaching? Like People!

Hey, there, it’s GeePaw! And you are watching the first ever GeePaw video aimed specifically at coaches. I hope you like it.

Do you know what the first absolute prerequisite for being a successful software development coach is? You have to like people.

You have to like people. You have to like their style. You have to like their resistance. You have to like when they do the thing you want them to do. You have to like when they don’t do the thing that you want them to do. You have to like people.

We get into this business because we’re very hot on a system, or a method, or a technique, or a something, and we want to share it with everybody.

But it’s really easy to get caught up, caught up in the system, caught up in the method, caught up in whatever flame war is running around the building today. It’s important to remember, though, the secret requirement for all successful coaching enterprise, is to like people.

What I’m Not Saying

Now, before we get very far, we have to address a couple of things I’m not talking about. I am not suggesting that you have to be an extrovert, a person who gains energy rather than losing it by being around other people. You don’t have to be an extrovert.

And I’m not suggesting that you have to be some sort of rainbow-farting unicorn floating up in a blue sky with just enough fluffy clouds in it to prove to you that, truly, every day is a beautiful day.

You don’t have to be either of those two things. I’m not either of those two things, not even by a stretch. But I like people. I like how they think. I like what they smile about and what they cry about. I just like people. What can I tell you?

And if you’re going to be a successful coach, you have to do that, too. Now, listen, I’m a pro. And I always find something nice to say about every team that I work with, because it’s a perfectly ordinary and healthy part of the job. I admit, sometimes, it’s a really big stretch. Gosh, you know, you guys just have the best shoes of any team I’ve ever worked with.

But truthfully, I like people.

I like knowing how so-and-so met her significant other. I like knowing why so-and-so became a geek. I like knowing what happened at the house last night over dinner that was funny? I like knowing that my friend buys tons and tons of video games but never ever has time to play any of them. All of those things, I like about people.

I like people because we’re so messed up and we try so hard.

That’s my secret to liking people. That’s what led me to like them so much.

We’re so broken. I’m broken. You’re broken. Everybody around you is broken. And yet, we’re all trying so hard to be who we want to be, to do the right thing, to be kind, and strong, and fast, and smart.

And that is what let’s me like people so much.

Play More Favorites

Let me ask you something. Do you ever play favorites? Are you ever a little warmer to somebody else because they’re one of your favorites, a little more tolerant of them, a little more cheerful around them, happy to see them, happy to listen to them, happy to talk about things that don’t have anything at all to do with work?

So do you play favorites?

Good.

Keep it up. Play more favorites. Pick more favorites to become your favorites.

Remember The Last Time?

Do you remember how it felt when you were listened to, when you were asked, when you got help from somebody else, or you gave help to somebody else, when you were regarded kindly by someone?

Do you remember how powerful you felt, how much stronger, how much more whole, how much more hopeful about what was coming in front of you, and about the possibility of you actually pulling it off?

So. Dig it.

Do more of that.

I’m GeePaw, and I’m done.