I don’t know. Sometimes I feel like some of these folks try too hard to soft-sell the excellent way presented by test-driven development (TDD) and pair programming (PP). A lot of alleged agilists make this argument: you see, by PP’ing and TDDing, you will greatly increase your quality, so even though your productivity goes down, you get the coolest glow by knowing in your heart of hearts that you are a good citizen of the coding world.
I call bullshit. Not only is it not true that you can trade internal quality for more features, it’s actually the exact opposite case: the more productivity you seek, the higher you should raise your standard of internal quality.
That’s right, that’s what GeePaw says. If you want more production, look first to raising your internal quality. So, how can such things be?
- Because internal quality and external quality are not the same things.
- Because the biggest single determinant in today’s production is the quality of yesterday’s production.
- Because typing is not now and never has been the bottleneck in writing code.
If you’re okay with those ideas, then move along, you’re good for today. If you’re not okay, then follow me into the explanation of these facts.
Internal vs. External Quality
In software, there are two different types of quality, internal and external. External quality is about the “saleability” of the software you’re making. If there were a number to represent how many features you have, or whether those features are correct across the entire range of possible inputs, that number would be the external quality. Now, notice, external quality can be traded for time-to-market. It’s not traded for productivity per se, but it’s a perfectly delightful way of hitting your ship-date.
Internal quality, on the other hand, is about the code. If you have to have a number, think McCabe complexity, or something like Crap4J puts out. It’s about crossing your t’s and dotting your i’s. It’s merciless refactoring, delightful pairing, and using microtests to drive the code. I reiterate for the obtuse: you can not go faster by shorting internal quality unless you are a noob.
Yesterday Determines Today
Do I really still need to rehearse this? All day long, every time you make a move, you will be depending on the code that’s already there. Every line of it you have to study will slow you down. Every extra open dependency will slow you down. Every bad variable name will slow you down. Every flawed design decision, be it big or small, will slow you down.
If you want to work as fast as you can, you want to work with clean code. Period.
Typing Is Not The Bottleneck
The most common reaction to pairing and TDD is to suggest that they’ll really slow the team down. It’s obvious, isn’t it? If two people sit at one machine, that’s got to mean that we have 50% less hardware utilization, which has just got to hurt our production. And don’t even get me started on the TDD: tests are code. If I can only produce 100 lines of code a day, and you expect me to have that code driven by tests, you’re basically telling me to write just 50 lines of code and 50 lines of test. So it could not possibly be the case that TDD and pairing will help my production.
Yes. You’ve run rings around me logically. Two people together can code as fast as two people separately because, get this, the hard part of coding isn’t the part where you type. When people say they ‘coded’ all day, what do they really mean? They are usually saying they:
- typed in code;
- drew some pictures;
- ran the debugger;
- waited for the debugger;
- figured out how to set the breakpoint so you got your failure case;
- read 20-50 times more code than they wrote;
- asked peers to look at a problem;
- got asked by peers to look at a problem;
- stared into space;
- threw some kind of something at other people;
- surfed the web looking for answers;
- and so on…
Notice that writing code into the machine occupies only a very small portion of this list. That’s because the hard part of programming is the thinking, not the typing. Everything else on that list (except possibly the throwing stuff) is about thinking, not typing.
TDD increases your production because it serves as a thinking-aid. It limits back-tracking and gold-plating and it reduces code-study and debugging. Pairing increases your production for the very same reason. Two developers together don’t type as fast as two developers separately, but we don’t care: the bottleneck is the thinking, and pairing and TDDing both improve it.
If you want to increase the productivity of your team, then do these three things:
- write a microtest that fails before you change any code;
- adopt a “no-pair no-keep” agreement;
- establish a shared understanding of internal quality.
Alright, then. I’m glad we had this little talk.