How TDD and Pairing Increase Production

"Test-driven Development" and "Pair Programming" are two of the most widely known of agile practices, yet are still largely not being practiced by many agile teams. Often, people will cite being "too busy" to adopt such practices as TDD and pairing; in essence, implying that striving for high code quality will reduce productivity. Mike Hill explains how this logic is seriously flawed.

Mike tells us, essentially, that one must "go better" if they want to "go faster":

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.
...
If you want more production, look first to raising your internal quality.

And then he tells us why:

So, how can such things be?

1. Because internal quality and external quality are not the same things.
2. Because the biggest single determinant in today’s production is the quality of yesterday’s production.
3. Because typing is not now and never has been the bottleneck in writing code.

Mike follows by expanding on these three reasons.   First, he clarifies the word "quality" to distinguish external quality, which can be thought of as the amount of features in your product, from internal quality, which refers to the code that is behind those features. He makes this distinction to note that while external quality can be lowered to shorten time-to-market, internal quality cannot.

Next, Mike describes how "yesterday determines today", or how internal quality of existing code affects your current productivity:

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.

Finally, Mike takes on the common misconception that pairing and TDD decrease throughput (productivity) because you'll have [this author's words] "half as many people typing half as much production code". He gives a list of 11 common activities that occur when someone "codes", then has this to say:

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 [not the typing], and pairing and TDDing both improve it.

Mike concludes with three summarized suggestions to improve your team's productivity:

If you want to increase the productivity of your team, then do these three things:

1. write a microtest that fails before you change any code
2. adopt a “no-pair no-keep” agreement
3. establish a shared understanding of internal quality

It's likely you know someone (possibly even yourself) who believes they "don't have time to pair or do TDD".   Mike's article can help you.