Perks and pitfalls of pair programming
Brother And Sister Fighting Over Remote Control image via Shutterstock
In his memoir, Steve Wozniak offers this recommendation to inventors: “Work alone…Not on a committee. Not on a team.” Programmers may or may not agree with his guidance, but the truth is that the success of pair programming is often influenced by a plethora of premises.
Studies have shown that paired developers take only 15 percent longer than individuals to complete a task, but what makes the difference between pair and lone programming is the corresponding increase in quality of roughly 15 percent. Jonah Lehrer wrote in a New Yorker piece that decades of research have arrived to the following conclusion: that brainstorming groups have fewer ideas than the same number of people who work alone, but they fructify the group’s ideas by pooling them.
Perks of pair programming
The manner in which programmers are grouped has a clear impact on the result. There are at least three instances that could make or break a team of programmers. First, there is the option to pair an expert with another expert -this way, you have the chance to pool the best minds in the organization for a project that requires special attention, but the obvious drawback is that the rest of the team remains without their best performers. Second, there’s the option to pair a novice with an expert, which will import the wisdom of a senior team member onto new starters. Finally, novice-intermediate shortens the time it takes for new hires to become rightful contributing members of the team because of the first-hand exposure to the way the company works.
Plus, pair programming ultimately benefits the company. It may or may not increase performance, but it surely prevents developers from getting distracted, therefore from making mistakes that could cost the organization valuable resources such as money or time.
Why pair programming fails and how to turn things around
Pair programming may have its benefits, but a New York Times article points out that “people are more creative when they enjoy privacy and freedom from interruption.” Research proves that programmers’ performance is not necessarily influenced by the experience of working at a certain company or better pay “-it was how much privacy, personal workspace and freedom from interruption they enjoyed,” the piece claims. These findings go hand in hand with Picasso’s attitude towards solitude and creativity. “Without great solitude, no serious work is possible,” the painter once said.
In a piece published on Medium, Marcellus Pelcher, a software engineer at Google, encourages the idea of pair programming but warns about a handful of pitfalls that may prevent you from having a good session. One of them is failure to define tasks, which identifies the lack of plan as a leading problem that transforms pair programming into a mess. Pelcher believes that having small, yet concrete tasks which can be completed within roughly two hours is the key to success and claims that a session should consist of one or two tasks.
Worrying about sharing credit is one aspect that can ruin pair programming because programmers want to completely own a piece of code without anybody’s help. However, “not sharing credit is short sighted,” Pelcher says. Sharing knowledge, building camaraderie and learning new things about programming are just a few benefits of not caring too much about who receives credit. When pair programming consists of an expert and a novice, the former often evaluates instead of participating. However, too much criticism can kill creativity, so assessing the skill level of one’s colleague should be the byproduct of the session, not the objective.
The fear of exposing gaps in knowledge may be another reason why pair programming goes down in flames sometimes. According to Pelcher, the beauty of programming is that one cannot know everything, which is why we need pair programming: to combine knowledge and ultimately achieve better results.
Pair programming is not a one-size-fits-all type of approach, but the amount of time one spends with another programmer has a certain influence on the quality of their work. “Since pairing is intense, pairing for only one to three hours a day is reasonable,” Pelcher claims. Therefore, it can be stated that the ramifications of the pair programming dilemma are endless, but dealing with them ultimately influences the value of a pair programming session.