Different Flavours of Pair Programming

Pair programming – two developers working together at a single computer – can result in better software written faster, but only if you know what you do.

Pair programming is not just sitting together and code as you would when being alone. Unfortunately, this is what most developers practice – resulting in a painful and ineffective experience.

To get most out of pair programming, you first have to know your setup.

Pair Programming for Transferring Know-How

This is the case when an expert and a novice pair together and the expert is coding while the novice is looking over the expert’s shoulder.

The expert shows the novice how something is done: coding style, design pattern, business logic concepts and so forth.

The novice gets an overview very quickly. However, the learning effect is rather low because of the passive role of the novice.

This kind of pair programming is very useful when introducing the novice to a new area.

Educational Pair Programming

When you switch the positions of the expert and the novice, you get educational pair programming. The expert coaches the novice while he tries to solve the problem. The learning effect is much greater in this kind of pair programming. But the speed of development is considerably lower.

Real Pair Programming

In real pair programming there are two experts working together to solve the problem at hand. Although they work at the same time on the same problem, their job is slightly different.

One (the driver) is responsible for

• typing code
• finding a solution that works

The other (the navigator) is responsible for

• challenging the current solution (what is missing? what could go wrong?)
• where to go next

This results in discussions about design, coding style, readability and much more. The outcome of such a pair programming session is a piece of code that is simpler, better understandable an less bug prone.

Pair Programming and Test Driven Development

Pair programming is especially powerful when developing software in Test Driven Development manner.

The driver is mainly responsible to get the failing test working by finding a quick solution (failing test phase). The navigator looks for test cases that show that the current solution is wrong or makes wrong assumptions (green tests phase). Together they look for simpler implementations (refactoring phase).

Why Pair Programming works

When practising real pair programming, both developers can concentrate on a single thing: Either finding a solution to the current problem, the current failing unit test, or challenging the current solution with new test cases.

This results in less switches between problem solving and problem analysing mode (red – green phases). Less switching between these two tasks results in higher efficiency¹ (less downtime because no task switch) and higher effectiveness² (navigator keeps focus on what has to be done and does not get lost in programming details). Finally, two developers can motivate each other much better to refactor code to get simpler solutions than a single developer does himself.

A final note: pair programming like any other methodology or practice has to be learned. Two developers cannot just sit together and expect to get benefits right away. Pair programming needs a lot of trust and discipline. Both has to be built first.

¹ efficiency = doing something quickly

² effectiveness = doing the right thing