Pair Programming: Advantages and disadvantages of Pair Programming

Pair programming is a practice used by teams that adopt Extreme Programming (XP). It is a controversial practice, which says that all code produced by a team must be produced in pairs.

“When there are enough eyes, all mistakes are obvious” — Eric S. Raymond

We will now see more information about how to work as a pair, the advantages, and the difficulties of pair programming.

Pair work

Anyone who has ever traveled on a plane knows that the aircraft has a pilot and a co-pilot. In practice, the pilot is perfectly capable of flying alone, however, would anyone have the courage to get on a plane without a co-pilot? What would happen if the pilot had a problem, or even made a mistake during the flight? This is the principle of pair programming. Two people, together, work better than two isolated people.

How it works

During implementation, one programmer acts as a pilot (typing the code) and another acts as a co-pilot (reviewing what is being typed, pointing out problems and thinking about the solution as a whole).

At each given time cycle, professionals change roles. In this way, the pilot takes on the role of co-pilot and vice versa.

Benefits

So far, nothing seems to justify the investment of having two people performing the same task, after all, software development does not involve as many risks as aviation. However, pair programming brings several advantages to everyone involved:

• Two minds think better than one. Do you know when you’re working on a task and get stuck for hours on a problem in your code? So when you work in pairs it happens less often, because there are two people thinking about the problem and trying to find the solution.
• Sharing experience. The cool thing about working in pair programming is the exchange of experience, each developer has their own style of writing code, or might use a framework that you had never used before, it is always good to learn new things.
• Learning to be patient. When you work with another person you have to know how to listen and understand that each person thinks differently. Another thing is that when they are doing pair programming and the person who is at the computer writing the code has to take into account everything that the other person is writing and whoever is as an observer will always make a comment or add something while the other writes the code so it helps to exercise patience.
• Greater Concentration. When you work alone the chance of being distracted is greater, so pairing is great because there are two concentrated people trying to make it happen. Also, one person ends up depending on each other to finish that task, so you don’t want to harm your co-worker, do you?

Difficulties

There are, of course, some difficulties in adopting pair programming. The first of these concerns the personality of the developers involved. They must understand that the code produced is collective, not their property. They must also accept suggestions and criticisms of their work, understanding that this is due to the fact that the ownership of the code is collective. Another great difficulty is convincing “who pays the bill” that it is worth it. However, this can be done using practice. Performing some experiments with pair programming, comparing the result with solo programming, it is usually concluded that pair programming is extremely advantageous.

Tips for working together

It may not seem like it, but working in pairs is not that simple. Some tips can help teams work in pairs:

• Understand how people work. To work together, each partner must understand and respect the way each of them does things. This must be explained by everyone so that there are no doubts and mistakes at the time of pairing. For example, some people like to work with diagrams, others prefer to analyze the code before starting. The important thing here is that the couple is aware of the way each works, and can put together a work scheme for him.
• Perform frequent pair exchanges. Pairs must be switched frequently. This can be done every sprint, every day, every shift, this frequency must be defined by the team. It is important because people are different, each one has different knowledge and skills from the others. The best way to guarantee a good rapport and a good transfer of knowledge is to mix them.

I hope that with this article the benefits of pair programming have become clear. I know that the topic is very controversial, however, it is something worth trying at least. After all, such a controversial practice would not have so many advocates if it did not deliver results.

References

Benefits of pair programming, FreeCodeCamp.

On Pair Programming, Martin Fowler.

PairDraw, simulation of pair programming.