Pair Programming: Having More Than One Brain

In a new era, where remote work seems to be the most sustainable way of working, there are tools that have reached their potential. Collaborative coding tools have increased in number and quality. It seems that pair programming was born to be the perfect technique for today.

Usually, programming has been seen as an individual activity. The personality of programmers has been generalized and popularized as lonely people with little communication skills, and nerds.

The collaborative character in software development has been underestimated. The worst part of this narrative has permeated companies: computer scientists are awkward people who hardly talk about understandable things.

Far from this reality, from the perspective of agile software engineering, more and more organizations believe in high-performance teams. High-performance teams are not made up of extraordinary people. In fact, what makes them really good is how they communicate themselves and how effectively they are working together. That’s why in this post we will expose one of our favorite tools, pair programming.

Even though this is not about how pair programming works, this post exposes why pair programming is a tremendously enriching technique, and why it should not be underestimated by many managers or c-levels.

Having more than one brain

Pair programming is a simple concept, two developers team together on one computer. Behind those simple concepts, there is a collaborative effort that involves a lot of communication and focus.

Pair programming is a subset of a methodology called Extreme Programming (XP). XP is a set of human-centric software development practices that were created to produce high-quality software and to adapt to evolving and changing requirements.

Pair Programming is not about catching typos that can’t be caught by a linter or compiler. It’s about having a second brain. A brain that maybe builds thoughts in a totally different way from yours. It helps you give good names to classes, methods, and variables and write clearer code. Rethink architecture, apply helpful design patterns, and solve the problem from a different perspective.

This will allow us to not act on first thoughts. To spend too much time digging into a problem from the wrong perspective or to avoid distractions. Also, seeing how other people resolve problems can enrich your capacities and skills.

And finally, that’s a tool for increasing team cohesion. There is no stronger team dynamic than having to work on a real problem side by side.

Pairs and Code Reviews

Let me start with a classic idea: we have extremely good code reviews, pair programming is a waste of time.

Every time I hear this assertion three thoughts come to mind. The first is that collaborative work is underestimated. The second is that there is a lack of communication inside the team or there is not enough trust to pair. The last one, you want to go fast, but it’s not important to go on the right way.

When you do code review, you start building your mental model from the other developer's point of view. In the code review, you put yourself in the mind of another person and look for the task to be well done. Given that this mental model is not yours, you often end up narrowing the final solution to accommodate it to the work that has been done.

Pair programming is a constant live code review, where we iteratively are finding the best solution and building a mental model together. We do not review a final solution, we try to find together the best approach to a problem. We build and think together on this problem, agreeing from the very beginning on what the problem is.

In some cases, people think of exceptions to this rule, for example when two inexperienced programmers pair together. But if this is the case, wouldn't it be a good idea to add a third more experienced, developer?

And you know what? That’s perfect for remote environments. Pair programming keeps developers in a constant non-artificial collaboration. There is no need for team-building activities or extravagant company culture to create a collaborative environment, pairing creates this culture.

Pairing is not about velocity

Our common sense, tells us that two people working on the same problem will reduce the time needed to complete a task by half. That’s not the case, pairing is 15% slower in lead time to changes. Pairing is about quality, avoiding rework, saving maintenance costs, increasing sustainability in code,reducing misunderstood problems, and avoiding bad architecture decisions. Speed is a circumstance problem, quality a business-core problem.

There are some revisions about the costs and benefits of pair programming. Alistair Cockburn and Laurie Williams wrote 2006 an extended revision about that [1]. On it, they conclude,

The development cost for these benefits is not the 100% that might be expected but is approximately 15%. This is repaid in shorter and less expensive testing, quality assurance, and field support.

As we see, the benefits of pair programming are multiple. It improves your team's culture, communication, and quality. All while not heavily affecting your short-term performance. In short, it helps you to build an exceptional team.