Pair Programming - The Whole is Greater than the Sum of its Parts
When was the last time that you did some pair programming? How often do you practice it and why? Is it actually pair programming or is it just two people sitting side by side?
What is it?
Pair programming is an extreme programming (XP) practice. According to Kent Beck’s book, “Extreme Programming Explained: Embrace Change” it is
A programming technique where two people program with one keyboard, one mouse, and one monitor
So, essentially, two software engineers, working on the same task, in a single machine. Two roles are defined and used by the participants, ideally swapped frequently: the driver and the navigator.
- The driver is writing the code, focusing on the task in hand and in the micro view of the code.
- The navigator is constantly reviewing the code being written by the driver, is looking for logic problems and bugs and is thinking ahead of the architecture and design of the system, focusing on the macro view of the code.
Now, having decided to pair, how do you go about doing it?
The sum is greater than the parts
Pair programming is a powerful technique when you need to tackle a very difficult problem. The reason is that, empirically, the quality of the work that is being produced by the pair is higher than the one of the work that each team member would produce on her own. I know that it sounds strange and is indeed very counter-intuitive, but, surprisingly, I have found it to be true every single time that I have paired on a difficult task. When done right, the level of concentration is unprecedented and two minds, deeply focusing on the same problem, can produce extremely high-quality work.
You have to be skilled to mix talent. You can’t just slam a bunch of developers in a room and expect better code and faster code production. Think about it: It takes a woman 9 months to make a baby, but 9 women can’t make a baby in 1 month. That’s not a totally accurate parallel to software development, but it gets the point across. Some pieces allow for only one person at a time, and adding more people won’t help. For a lot of projects, it helps to be able to break them up into smaller pieces and work on them simultaneously. Breaking things up takes planning and coordination, though. We don’t just all rush off in different directions.
More difficult to cut corners
We do get tired when writing code. Especially, when solving hard problems. These are the moments when we get more prone to cutting corners. “Let’s skip this unit test”. “I could improve this, but let’s leave it like this for now and I’ll refactor in the future”. We’ve all been there and it is quite natural when we grow really tired. We still know the right thing to do, but we lack the discipline to do it at this given moment. When working in pairs, cutting corners is more difficult. Usually, either the navigator will “push” towards the right direction or the driver will feel less at liberty to opt for a dirty solution.
Increased collaboration
Gone are the days that software was produced by individual sitting in their cubicles, working as isolated as possible. Nowadays, it is well understood that great software is delivered by great teams. Therefore, we focus our energy a lot into building great teams. Honestly, I can’t think of a more catalytic action to this than having two people working together, on the same problem. Personally, as a scrum master, I always encouraged the team to work in pairs as much as they can.
Pairing remotely
Remote work has evolved in an integral part of software engineering teams. I used to think that pair programming would be very difficult (if not impossible) to do when the team members do not share the same physical space. After all, this technique is heavily based on the benefits of direct communication and interaction. I recently gave it a try nonetheless, and the results were remarkable. Not only it worked, but the outcome was of excellent quality.
Retrospectively, I gave it some thought and tried to understand why it worked in such a great way. I realized, that neither communication nor interaction is negatively affected when using modern technology in the right way. Online call and remote control tools allow us to work seamlessly on the same machine. Besides, each participant is comfortably sitting before her dedicated screen and keyboard, without even feeling that her personal space is invaded, which might be the case when first adopting pair programming in person.
I would strongly recommend to give remote pair programming a go and the results might astound you, just as they did me.
Conclusion
Pair programming is a truly powerful technique. It brings high-quality results, increased levels of collaboration, collective code ownership and loads of other benefits. Studying the technique is important in order to apply it correctly to gain all these benefits. As responsible, professional software engineers, we should empirically find out when of for how long to use it in order to maximize the advantages for our team. Working remotely not only does not hinder pair programming but, with the right tools, it can leverage the merits. Finally, don’t be discouraged by challenges. As always, they will present themselves, but they can be overcome.
