By Jan Grape, Agile Architecture
Pair programming involves writing code together with a colleague. Two people share a computer, keyboard and screen while designing, creating test cases, and coding as a pair.
This might seem like an inefficient way of working. After all, wouldn’t it be faster if the two of you were typing away simultaneously instead?
That would be true if programming were about typing characters fast. But as we know, it’s not. Programming is about problem-solving. Every piece of code is the solution to a small problem. So creating software is about breaking down bigger problems into a string of smaller ones and solving them in sequence.
It’s a lot easier to solve problems if there are two of you. You can bounce ideas off each other and give each other feedback on the code, design and intentions even before you touch the keyboard.
The limiting factor when creating code is your ability to understand the problem, to break it down into smaller steps, and to know how to implement the solution for each step, all while keeping the bigger picture in mind and not creating bugs along the way. This is easier if you are not alone.
Studies show that pair programming is faster than solo programming, especially if you take into account the time wasted on building the wrong thing (misinterpreting the requirements) and fixing defects that could have been avoided (higher bug density).
In addition, pair programming means that at least two of you know the code intimately instead of just one.
How it works
In pair programming, the two developers usually play the roles of driver and co-driver, much the same as in a car racing rally.
Image: pixabay.com
The driver has the keyboard focusing on the present, writing the code while explaining what he is doing out loud.
The co-driver is thinking ahead on what is coming up next while also providing feedback on what the driver is doing now. There is constant chatter between the two while code is created and problems are solved.
Image: https://commons.wikimedia.org/wiki/File:Pair_Programming.jpg
After a short while, typically 20-40 minutes, they switch roles. Pair programming is not about a master telling an apprentice what to do. It’s about contributing on equal terms to create solid code accurately and fast.
The experiment at Tobii
Despite all previous studies showing benefits from pair programming, introducing the practice as a regular habit can take some convincing for some. This was true for a group of senior Agile teams at Tobii. Tobii (formerly known as Tobii Technology AB) is a Swedish high-technology company that develops and sells products for eye control and eye tracking [Wikipedia].
To evaluate the effects of pair programming Tobii decided to perform an internal experiment. A group of teams committed to trying pair programming for a few weeks followed by a survey.
About 20 people participated in the experiment and the majority spent 8-40 hours pair programming. About two-thirds of the people paired with 2-3 different partners, the rest with only one.
Almost all participants took on both roles (driver and co-driver) during the experiment.
Outcome
For an organization that needed quite a bit of convincing to adopt pair programming, the results of the test were surprisingly positive.
A majority of participants saw positive results of pair programming and very few (almost none) were strongly against it.
In general, pair programming was found to be:
Faster
Produce fewer defects in the code
Enables you to learn new things
The notable exception in the responses in the survey was code reviews. Tobii is very adamant about its code quality and has done code reviews for decades as an important part of its quality assurance and knowledge sharing.
Pair programming was not considered a replacement for code reviews, although some felt that it made the reviews faster.
