Why Pair Programming Works

The October 2002 Leadership & Management article explains why motivation programs fail - they ignore the human factor. Research shows that people resent being treated as automatons in an assembly line. Specifically, it shows that any form of manipulation - even attempts that are well intentioned - reduces productivity and cooperation in addition to increasing stress and job dissatisfaction. This situation is further exacerbated when creativity and quality are core traits of the employee's job. Since IT departments rely heavily on these two traits, improvements to software development need to take into account the human factor. Pair Programming is one such "human" solution. It partially solves the motivation problem by focusing on the "Three C's" suggested in the October article: Collaboration, Content and Choice. In addition, Pair Programming takes advantage of the fact that more than 70% of programming effort is thinking. Finally, Pair Programming naturally eliminates dysfunctional behavior by exposing it.

How is Pair Programming a "Three C's" solution?

To wit, Pair Programming improves collaboration. As stated in the October article, "On most tasks, especially those that involve some degree of complexity and require some degree of ingenuity, people are able to do a better job in well-functioning groups than they can on their own. They are also more likely to be excited about their work. Both effects are due to the exchange of talent and resources that occurs as a result of cooperation - and also to the emotional sustenance provided by emotional support. People will typically be more enthusiastic where they feel a sense of belonging and see themselves as part of a community than they will in a workplace in which each person is left to his own devices." To begin with, Pair Programming "encourages the exchange of talent and resources" by creating an atmosphere of unity and team building. Another positive aspect is that team members provide immediate and non-threatening feedback as part of the "emotional sustenance" provided by the group. Another reason peer feedback is preferred is that it is less threatening than managerial feedback. Employees often feel that their job is at risk when their manager provides negative feedback. On the flip side, employees feel manipulated when the manager makes positive remarks since, in fact, those comments stress the power relationship of the giver. Finally, emotional sustenance occurs naturally when the pair solves a difficult problem together. In demotivational workplaces, people try to get the emotional support by sharing their success with others. In that environment, success is seen as a threat and often results in a negative political backlash. Pair Programming eliminates this situation by allowing pairs to pat each other on the back for a job well done. This positive situation can be enhanced for the entire team if pairs periodically rotate.

In addition, Pair Programming improves content. The October article addresses content by wondering, "What is a good job? ... It offers a chance to engage in meaningful work. (A good job) isn’t just that the process of working provides enjoyment, but that the product being made (or the service provided) seems worthwhile and important. ... The question is not just 'Are we having fun yet?' but 'Are we making a difference?'" Even jobs that don’t seem interesting can be made palatable if offered "a meaningful rationale for doing it anyway (in terms of its indirect effects, for example), and giving people as much choice as possible about how they perform the task." Pair Programming does this in two ways: firstly, by varying assignments, and secondly, by varying pairs. Providing varied assignments improves content by exposing programmers to new technologies which leads to continual improvement and fewer feelings about the job being stale or a career dead-end. Providing new pairs improves content by exposing programmers to new ideas, new ways of thinking and new problem solving skills. Also, varying pairs limits the impact of personality conflicts. Finally, not all projects or project tasks are "interesting". However, rotating these uninteresting tasks between pairs shows employees that they will only have to do them for a short time and can then get back to the more challenging tasks.

Finally, Pair Programming is a "Three C's" solution because it improves choice. According to the October "motivation" article, "We are most likely to become enthusiastic about what we are doing ... when we are free to make decisions about the way we carry out a task. The loss of autonomy entailed by the use of rewards or punishments helps explain why they sap our (personal) motivation." Most IT projects have the timeline "mandated" by upper management. These timelines are nearly always unrealistic. Putting employees into such a manipulative, powerless, demotivating environment is a guaranteed way to cause the project to run significantly over-budget and over-schedule. On the other hand, allowing programmers to choose from a list of deliverables empowers them to feel more self-directed and enthusiastic about completing the deliverable. Empowerment can be increased further if the team is allowed to realistically "choose" the amount of effort needed for each deliverable. This bottom-up approach may take longer than the "mandated" timeline, but will be completed significantly sooner and cheaper than projects that are driven using the typical top-down approach.

Brain Power

Simply put, 70% - 90% of programming effort is spent on thinking, discussing and understanding the problem. Another "brain power" issue to consider is the productivity gap... 10% of the programmers produce 90% of the code.

With this in mind, Pair Programming is a natural fit. To start with, it takes advantage of the fact that "two heads are better than one." Anecdotal evidence suggests that pairs nearly double the productivity compared to two programmers working independently. The evidence also suggests that the quality of the pair solutions is significantly higher. With two pairs of eyes, programmers are more likely to see bugs earlier in the process. Also, thinking and discussing the problem is more likely to result in a simpler, cleaner solution: fewer lines of code means less chance of introducing bugs. In addition, as the pair better understands the problem, they are more likely to catch missed requirements. Since missed requirements are often submitted as "bugs" during user testing, the earlier they are found the less expensive the implementation will be and the higher the perceived quality (since there will be fewer bugs submitted to be fixed). Finally, pairing programmers mitigates the problem of "tunnel vision". A counter-part lessens the chance that a programmer will get ego-locked into his "own" solution. Eliminating ownership and removing ego is critical to creating an atmosphere of team building. Removing ego encourages alternate solutions with minimal emotional impact when a solution is discarded.

In addition, Pair Programming increases "brain power" through built-in knowledge transfer. Firstly, Pair Programming provides a natural mentoring structure. Pairing junior programmers with senior programmers provides an opportunity for junior programmers to learn the practical experience honed over the years by senior programmers. Not a single training class exists that can teach this real world experience. Next, Pair Programming eliminates the risk of "knowledge pockets". By having a wider range of people working on more parts of the system, system knowledge is shared by all project team members. Projects are no longer at risk when, not "if", a single team member working on a key piece of code leaves the project. Next, Pair Programming lowers the project's learning curve. Having a knowledgeable, dedicated resource to answer questions speeds up the learning process significantly. In most situations, a new member will be able to start contributing (albeit, in a limited fashion) their first day. Lastly, Pair Programming reduces the need to create or attend project- or technology- focused training classes. This form of training is very costly in terms of direct costs (trainer, room, meals, etc.) and lost opportunity costs (unavailability of the trainer and employee, keeping training material current, knowledge loss over time). Training classes are relatively inefficient and offer few benefits compared to what can be achieved with Pair Programming.

Exposes Unwanted Behavior

In other words, Pair Programming eliminates unwanted, dysfunctional behavior because team members' actions are visible to the other member of the pair. To begin with, people are less likely to make poor choices. When a peer is watching, some behaviors will be avoided because the programmer doesn't want to perceived negatively. When a superior is watching, they simply hide the behavior until the superior leaves. This works because peer interaction will focus attention on the task at hand. It will eliminate easy problems like casual web browsing and personal emails. However, this philosophy implies that employees want to do the right thing. In a seriously dysfunctional work environment, this may not be the case. Employees may just not care.

Another problem that Pair Programming quickly exposes is when an unskilled developer tries to hide his lack of knowledge or ability. This type of programmer can be identified through evasiveness and unwillingness to communicate with other team members. Often times, these unskilled developers will refuse to share knowledge or attempt to sabotage team unity. Pair Programming does not directly fix this problem... a manager will need to intervene and reset this person's attempt at self-protection. Sometimes, all they need is a reminder that every team member is valuable and is not being ranked by ability. Managers need to be very conscientious that this is truly the case.

Next, Pair Programming exposes and discourages prima donna-ism. Prima donnas often appear evasive and unwilling - just like an unskilled developer. The difference being that the prima donna is capable but doesn't have the confidence whereas the unskilled programmer isn't capable but projects assuredness. Prima donnas are very problematic: they often sabotage other team members, they horde expertise, and they become angry even in environments that encourage ego-less programming.

Finally, Pair Programming lessens gossip mongering. Essentially, gossip is a political maneuver to lower another person's power or status in a group. Pair Programming is fundamentally opposite to and discourages power structures. The main objective behind Pair Programming is to foster personal empowerment. In addition, people are less likely to hurt their peers when they have a personal, day-to-day relationship. Ultimately, gossip mongering is lessened because when people like what they're doing, that's where they put their focus.

Conclusion

Overall, Pair Programming solves "motivation" problems because it focuses on the three C's, recognizes that programming consists mostly of thinking and discussing, and eliminates dysfunctional behavior by exposing it. More specifically, Pair Programming is a three C's solution because it improves collaboration and teamwork, improves content by varying assignments and pairs, and, improves choice by giving programmers the ability to choose their own fate (tasks and time to complete). Also, Pair Programming facilitates thinking and discussing by recognizing "the productivity gap", by recognizing that two people are more likely to discover a more optimal and quality solution, and by easing the difficult task of knowledge transfer. Finally, Pair Programming eliminates "bad" behavior by exposing workers engaged in productivity draining activities, by recognizing and intervening on behalf of unskilled programmers, by exposing unwanted prima donnas, and lastly by eliminating most gossip mongering. Admittedly, Pair Programming won't eliminate all your ills, but can be quite handy for encouraging a high-quality, high-productivity work environment!