Apokalypse Software Corp.

Pair Programming is for Wusses

25 03 2007

I said it.

The sacred ritual of XPers is a relic and an obstacle to improving a team’s agility.

By way of explanation, let’s examine the definition of pair programming and its application.

In the first edition of Extreme Programming Explained, Kent Beck, gave this definition for pair programming:

A programming technique where two people program with one keyboard, one mouse, and one monitor. In XP the pairs typically change a couple of times a day.

(It used to be preached by the XP true believer that the pair must be physically present in the same location with one keyboard and one monitor to be effective, but this is no longer considered sacrosanct.)

The People, Projects and Patterns wiki gives an elaborated definition:

An ExtremeProgrammingPractice in which two engineers participate in one development effort at one workstation. Each member performs the action the other is not currently doing: While one types in UnitTests the other thinks about the class that will satisfy the test, for example. A single, unsubstantiated, unscientific, undergraduate’s survey has shown that, after training for the “PeopleSkills” involved, two programmers are more than twice as productive as one for a given task.

In this practice, the programmer operating the keyboard is often called the “driver” while the programmer considering a larger context for the code is “navigating” (as someone who follows maps and charts).

The key value-add of pair programming for agile development is communication: the ability for both programmers to share skills, domain- and system-knowledge and receive immediate feedback on the direction of their work. The state of the system is advanced as the skills and knowledge of the pair are raised.

All is Not Rosy in the Land of XP
Let’s examine the speed barrier posed by having both programmers being mindful of the development effort they’ve been assigned. As one programmer is driving the other is navigating, focusing on the code within the context of a greater part of the system. If he’s thinking about the bigger picture he isn’t focused on reviewing the keystroke-by-keystroke typing of his partner. So how often must he take the time to review the code written by his partner? Every other second? Every minute? Every half hour?

Sometimes, “Trust me.” is a suitable non-maskable interrupt, effective for a few minutes of coding while the navigator doesn’t know what’s being done. Those few minutes should be hours and days of which that programmer should drive his own stories and trust the tests and reviews and the training the other programmer has and the process itself will keep itself defective code in check.

Why Pair Programming Slows You Down

More People Requires More Communication
The fact you have at least one pair of programmers means they’re going to have to communicate. This is the key problem pair programming solves, but this method of communication is the bottleneck to doing it well. Since they don’t communicate via documentation, they’re going to have to sit in on each other’s work time. This adds some overhead of communication time to the work time.

Interruptions Hamper Productivity
When you are focused on one task, certain details are of more importance than others. As your mind ignores the details which aren’t essential to the primary objective you begin to function in the “flow” or “zone”. If you have to perform a mental context-switch to focus on the details of something other than your primary objective you can lose the intensity of that flow. This becomes far more frequent when paired with someone who is focusing on another aspect of the code or system.

Entropy and the Law of Diminishing Returns
As team members become more acquainted with the workings of the system, there is greater overlap of skills and knowledge and less insight to be gained from working on one development effort. This results in less productive use of each programmers’ time. It would be better to have each programmer work on different stories or different tasks for a given story.

Limited Scalability
With pair programming’s emphasis on communication, it readily becomes apparent that information will be slow to disseminate throughout a project when limited primarily to this practice. In addition, the more ambitious a project is, the less an organization is able to operate in an agile manner when constrained by pair programming. No matter how many experienced XPers you throw at a project, when you’re required to divvy them up into pairs you’ve locked your programmers into limited gains. Two is the bottleneck for communication and productivity gains rather than five or eight.

Insecurities, Arrogance and Disrespect Breed Competitive Friction
An antagonistic partner will undermine the effectiveness of what should be a cooperative endeavor. However, this point should only be considered a temporary issue for teams which are adapting to agile practices, or for members who should be considered temporary team members.

So Pair Programming is Evil?

Definitely not! It is a practice used by many fields, including software development, with great success. It should be common in every team as it has distinctive benefits for every development effort. In fact, XP uses pairing on occasions other than just for coding. A programmer will pair with a customer when writing stories. And a customer will pair with a tester to write acceptance tests. But pairing has limitations in benefits and effectiveness.

Pair programming is most effective:

When the skills of both programmers are slightly to moderately dissimilar.
When knowledge of the system between the two programmers is highly dissimilar.
When the story being coded hasn’t already been scripted, (i.e., the pair is designing on the fly).
When the team isn’t agile enough to break down assignments by functionality (e.g., test cases, coding, reviews).

Given that there are times when pair programming is effective, and times when it isn’t, it should seem reasonable to most to pair when it is more effective than programming alone, and not to when it isn’t. Because the key to agile development is being that: agile. The problem is when you fail to exercise common sense when using any practice, even ones enshrined in holy scriptures.

With whom should you pair? How often should you pair? and how long should a pairing session be?

â€œBegin at the beginningâ€, the King said, gravely, â€œand go till you come to the end; then stop. â€
â€” Lewis Carroll

Actions

Informations

Date : 25 March 2007
Categories : development, process improvement, software

One response to “Pair Programming is for Wusses”

20 04 2007: More Development Downtime for Improving Process Uptime | Apokalypse Software Corp. (07:56:47) :

[...] Jeff Langr wrote about the importance of pair programming, which I’ve already discussed before. [...]