Pair programming: pluses and minuses, bonuses and anti-patterns

Pair programming is one of XP practices. This practice embodies an extreme (hyperbolical) idea of code review. If the review practice allows improving the code quality, it’s easier to perform it constantly during refactoring and writing a new code.

The problem of a regular code review concludes in the superficial programmers’ feedback when they view your code. But as soon as developers start working with the code, they start providing the real feedback with all the flaws and weaknesses.

How to do that?

While pair programming two people sit together, side by side at one computer. One of them is a leader, he holds the keyboard and the mouse. The other one performs a constant code review of the first one to determine the tactic and strategic drawbacks in the code, including mistakes in the program syntax, logics, misprints and realizations that do not fit the current design of the system. After a certain time the programmers change their roles or the pairs themselves.

One of the most common reasons for doubts about PP among managers and programmers is: won’t the development become slower if two programmers work on one task?

The research show that in pair work is done either with the same speed as if the programmers worked alone, or a bit slower (15%). At the same time the code is much more qualitative and contains fewer mistakes (60%) in it.

Pluses:

• As a rule, code review (as a separate procedure) is not necessary any more.
• Even the most experienced developer can not know everything. The presence of 2 developers allows solving the tasks quicker and more effective.
• The number of mistakes decreases. Besides, the mistakes themselves can be detected in the course of work.
• Developers concentrate on work better and get distracted less. This point can be considered as a minus as well. Breaks are still necessary, that’s why pair programming requires 10-20 minutes pauses every 40-60 minutes.
• Developers know most part of the code. Thus, if needed they’ll be able to make modifications more effectively.
• In case there is required a two code parts confluence, PP is a quicker and more effective way, than if one developer wrote the code and afterwrds sent it to his colleague giving the explanations on the way.
• Programmers learn to solve the problems, discuss the issues and find the compromise collectively.

Minuses:

• Not everybody wants to work in pair. For somebody it’s psychologically uncomfortable, somebody can be not satisfied with the partner. Besides, the code of every developer is unique to some extent.
• Most of the managers will think that it’s not profitable to put two people for performing one task at one working place. The costs of development may increase, although it’s compensated with one significant advantage – improvement of internal architecture and fewer mistakes in the code. In 1999 there was held a research on time expenditures. According to the experiment, the time spent has increased by 15%, nevertheless, the quantity of the mistakes in the code has decreased by the same 15%. Also, it’s worth remembering that editing mistakes at the development stage saves a huge amount of time at the supporting stage.
• It’s necessary to coordinate the developers’ timetable.
• Human factor. For pair programming one needs to have patience and a desire to work in pair. If one of the participants just sit and watch, or start dominating without listening to his colleague’s opinion, such kind of development will not lead to any satisfaction or a higher performance.

Bonuses:

1. Sharing of experience: It often happens that working in pair you learn about some new short keys, interesting tools for speeding the work. Anyway, you constantly learn something new watching the others programming.
2. Knowledge about the system: Regular change of pairs contributes to knowledge transfer about different system parts inside the team. It makes for tracking the process of system development better, improving the system design, not duplicating the logics
3. Collective code ownership: When everybody participates in writing all parts of the system, the personal class or build ownership is out of question.
4. Tutorship: As the practice shows, the easiest way to integrate into the project happens in the process of pair programming.
5. More communication: Communication inside the team helps building relationship based on trust. Standups and retrospectives certainly bring in some communication to the routine work, but it can not be compared with pair programming.
6. Coding standards: Sitting in pair, constantly passing on the keyboard and changing the pairs, programmers transfer their knowledge about coding standards applied on the project. You will not have to apply automatic tools for checking the code quality.
7. Improving the discipline: Working in pair one wants to show his interest and level of experience to the partner. So, shifting to the social networks to look through the latest funny pics would be problematic.
8. Fewer interruptions: While working in pair you will be less distracted by side factors. As the time of 2 people is more valuable, their work becomes twice more expensive.

Anti-patterns:

Pair programming can be much more interesting and enjoying than solo programming, if it’s done in the right way. And vice versa, it can become terribly boring, if there was chosen a wrong approach.

According to my observations, it’s rare that people do pair programming in the right way. Most attempts of pair programming are ruined with one of the following anti-patterns:

1. Watch the Master: Such situation happens if in pair we have a programmer who thinks (or even he really is) himself to be a guru in his area. The questions of a less experienced developer about the code that is generated by Master, are mostly ignored. There is also possible an option when he is constantly said to google it. The Master doesn’t hurry to pass the keyboard to the partner. When the keyboard is finally at his partner, the Master loses the whole interest to the process.
2. Dictator: One of the developers in pair always takes a tough and ultimate position regarding all the decisions that are connected with the current tasks. In such situation, mutual assistance or learning in pair is out of question.
3. “Bring us some coffee”: Pair sits down at the computer. One of the developers takes the keyboard and starts writing the code, saying to his partner: “While I’m writing the code, go and bring us some coffee”. It breaks the basic idea of a mutual involvement into work.
4. Silent partners: The partners do not communicate with each other, do not comment their actions and decisions in the course of work. With the absence of the feedback the core idea of pair programming is lost.
5. Distributing the tasks sitting at one table: Programmers sit in pair, take two computers at one table (f.ex. PC and notebook) and start working in parallel.
6. Uncomfortable place of work: The most frequent reason for being tired while working in pair is an uncomfortable position of the keyboard and the monitor for the “leader” at the moment. When the keyboard is passed from one developer to another, the one who got it doesn’t shift to the center of the table but leans to the keyboard thus creating some difficulties for his proper work.
7. The partner is occupied with his own business: During the work one of the partners moves away from the working place, checks e-mails etc.
8. Specific environment settings: Every time the leadership shifts from one partner to another, each of them starts reconfiguring the environment: tabs, fonts etc.
9. Own style: Each of the partners sticks to his own coding standards which leads to heated discussions and a terribly formatted code.

If you see the programmers work according to such anti-patterns, provide them with the feedback pointing out their mistake. The practice shows that simply a bystander can align the pair work.

In the end I’d like to say that I vote for pair programming in marathons, long-term projects, fully understanding that it becomes unbearable while working on short tasks.

Pair programming should be perceived as a tool, not a cure-all for all the problems. Such practice is really worth trying to understand where it will be useful and when you can manage without it.

Have you ever had such practice of PP? Please, share your impressions and thoughts on this point. It would be really interesting to learn your opinion.

Thank you.