Pair Programming

The tests and code you write represent costly investments. In an ideal world, you would assume that all developers have the training needed, and more importantly the desire, to effectively write quality code. Yet a glance at just about any existing system suggests otherwise.

In this book, I’ve tried to make the case that most systems are a mess because programmers don’t have a mechanism (such as TDD) to actively ensure the code doesn’t degrade. But other reasons abound.

• Lack of education: Too many developers don’t understand core design principles and constructs for coding well. Some think they already know enough and aren’t willing to accept that there’s more to learn.

• Lack of concern: Too many developers don’t care that they are producing difficult code. Or they justify it because the system is already rife with bad code.

• Time pressure: How many times have you heard “Just ship it—we don’t have time to worry about quality?”

• Lack of review: All it takes is one rogue developer to inflict serious damage on a codebase. Sometimes this developer comes in the form of a high-priced, short-term consultant. And sometimes the creator of the crummy code disappears before you uncover it, leaving you with an incoherent, unmaintainable mess.

• Lack of collaboration: In a team of more than one developer or in a codebase of any reasonable size, styles and quality quickly diverge. Understanding code written by another developer can be difficult without their explanation, and other developers may code solutions to problems that are already solved. Individuals may produce less-than-optimal solutions when they don’t seek the wisdom of others.

The Rules of Pairing

The technique of pair programming purports to help by providing an active mechanism for continual review, collaboration, and peer pressure. Here’s a summary of how pair programming works:

• Two programmers actively co-develop a solution.

• The programmers typically sit side by side (though other configurations, including remote pairing, are possible).

• At any given time, each is in one of two roles: driving, which means actively coding the solution using the keyboard, and navigating, which means providing review and strategic guidance. Pairing is not one person doing and the other simply sitting back and watching.

• The programmers in a pair swap roles frequently during a pairing session, potentially every time a test fails or passes.

• Pairing sessions are short-lived, with pairs reforming as often as every ninety minutes. A primary goal of rotating pairs in this manner is to increase knowledge, and accordingly reduce risk, across the team.

Much like TDD, studies of pair programming^[35] show increased quality and an increase in the initial cost of development. The aphorism “two heads are better than one” should come to mind. The increase in cost is not double, as you might at first think. The higher quality brought about by the active review is one reason. Peer pressure and increased levels of communication, coordination, and education might also explain the lower cost. Other benefits abound, such as reduced risk and increased flexibility.^[36]

Pair Programming and TDD

TDD supported with pair programming is a natural fit. Learning TDD is made dramatically easier with a support system in place. Developers are more likely to revert to old, non-TDD habits without a bit of peer pressure from their teammates. Sitting with an experienced TDDer can more than halve the time needed to ingrain the habit of TDD. Swapping pairs can help ensure that tests are written first and with care.

The cycle of TDD also provides natural role-switching points throughout a session. Many programmers practice ping-pong pairing. The first programmer codes enough of a test to demonstrate failure and then relinquishes the keyboard to the second programmer. The second programmer writes the production code that makes the test pass and then writes the next portion of the test (or the next test). Pairs might also alternate roles as they work through various iterations of refactoring the code once a test passes.

Pairs will from time to time debate the direction of the tests, particularly as they learn about each other’s preferred styles. The general rule of thumb is to debate no more than five minutes before one of the pair grabs the keyboard and demonstrates what they mean. Usually the direction the tests take will win out the discussion.

Pair Rotating

As indicated earlier, pairing sessions should be short-lived. The natural tendency, though, is to allow the pairing session to last as long as it takes to complete a task, or perhaps an entire feature.

Indeed, swapping pairs incurs the overhead of context switching. If you’re the new party to a pairing session (the newcomer), you must first discard your often deep thoughts about the last problem you were solving. (I’ll refer to the programmer you’re joining as the old hand.) For most folks, this is no big deal, and a break of five or ten minutes does the trick. But you then face the steeper challenge of coming up to speed on a new problem. Depending on its difficulty, that might take a few minutes, but it also might require detailed, time-consuming explanation from the old hand.

With TDD in play, the focus changes. Instead of a detailed explanation from the old hand, you focus on the current failing test. (If there isn’t one, you watch and listen as the old hand puts one in place.) Your goal is to read the name of the test and ensure it makes sense. You can then read the test’s steps to help complete your understanding of the current coding task.

Worrying only about a single test, particularly a well-written, laser-beam-focused unit test, can make it much easier for you to begin contributing. You don’t need to know all the details. Instead of providing a lengthy discussion of the details up front, the old hand incrementally guides you along.

The more a team practices swapping midtask, the easier it gets, particularly in a small team. But why not simply prevent swapping until the task is complete?

Remember that a key goal of pairing is review. Two heads are usually better than one, but it’s still possible for a pair to go down an unproductive avenue. This is even more likely as a pair digs deeply into a solution, at which point many find it easy to convince themselves that they have the only right answer. A third party, someone not invested in the pair’s deep, shared train of thought, can prevent bad solutions by interjecting with their untainted perspective.

Additionally, increasing swapping increases the likelihood that the newcomer is familiar with the particular area of code. With regular swapping on a modest-sized system, everyone ultimately gets their hands on all parts of the system.

Increased code quality can be another key benefit of swapping—if the team seeks and insists on it. Higher code quality can help further reduce context-switching overhead by reducing the time the newcomer requires to understand it. Code that isn’t clear must be reworked. Pairs should quickly learn that it will save time to continually refactor for clarity, especially with respect to the tests.

Pair swapping represents a trade-off between increased initial effort and long-term payoffs, much like pair programming itself, TDD, and many other aspects of agile software development. Context switching will indeed cause you immediate pain, which you can learn to abate over time. But a team full of siloed developers, with little review and no shared knowledge, will create pain that will only continue to increase over time.