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 efficiency1 (less downtime because no task switch) and higher effectiveness2 (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.
1 efficiency = doing something quickly
2 effectiveness = doing the right thing
[…] learn the difference between being the driver (the one holding the keyboard) and the navigator. See here for […]
[…] 2012 Goto comments Leave a comment Recently, I’ve given a short presentation about pair-programming and the stereotypes people show while pair-programming. As always when talking about […]
[…] / Infos der Präsentation von Urs […]