Home > Article > Backend Development > Why Pair Programming Is So Difficult to Practice
Pair programming helps improve software quality and strengthen team member cooperation. It has many benefits, but is it really easy for team members to pair up?
Marcos Brizeno, a computer scientist and consultant developer at ThoughtWorks in Brazil, shared his thoughts in his recent blog, describing why pair programming is difficult.
Marcos proposed the following challenges when doing pair programming:
Infrastructure: The team needs to have a dedicated workstation and provide common installations, such as editors, operating systems, etc.
Fatigue: Improving concentration is not easy. It takes a lot of energy to focus on a certain problem, share your thoughts and listen to other people's opinions.
Self: It’s important to stay humble and listen to other people’s ideas instead of arguing.
David Green, a software engineer at TIM Group, says pairing is not for everyone. He shared his views on his recent blog:
Any team is ultimately a mixture of people with different personalities. Extroverts prefer pairing up, whereas introverts tend to find this difficult and they try to avoid it. It's not necessarily a matter of education or persuasion, the benefits are relatively unclear, and even more introverted developers may find that the process is no more enjoyable than working alone.
Joe Barnes, the creator of ASCII characters, mentioned plagiarism as the reason the team stopped doing pairings.
I believe I have realized that the biggest thing that kills our teamwork is pairing. Always worrying about being plagiarized will directly lead to this result.
Marcos introduces a retrospective exercise called “That Person and This Person” to derive a set of best practices for pair programming on your team. Originally a retrospective event, the event information was co-posted by Paulo Caroli (Agile Coach at ThoughtWorks) and Taina TC Caetano (Developer Consultant at ThoughtWorks).
Split a wall into two sections, “Don’t be that person” and “Be that person!”: In the first section, members write down examples of behaviors they don’t like. The second section includes examples of behaviors that people really like.
Then, go to the wall and let the team discuss each example. During the communication, the team should discuss what they think of a specific type of behavior. Does everyone think this behavior is good? The behavior in some examples may be obvious and trivial to talk about, while others may be worth discussing in depth.
I think this activity is a good way to improve team morale. Having such conversations often makes people feel more honest with each other, thus increasing more communication. How to feel the motivation of the team? A better way is to observe how they talk to each other. Often, a quiet team means people are less connected and share less information.