Pair Programming: Two heads are better than one

Pair programming is the practice of two programmers working together on the same terminal and on the same task. I use the word task because the pair could be working on a design issue, coding, or even documentation.

One person is the driver and the other is the observer. The driver has control of the pen/keyboard, etc and contributes by coding or drawing design diagrams. The observer wears the hat of a strategist. He or she observes what the driver is doing to analyze its correctness and also to understand how well it fits into the big picture of the software being developed. Developers switch roles as well as pairs during the duration of a project.

Pair programming initially seems like a very unorthodox way of working. Developers are used to the notion of code ownership and solo programming. Some initial reservations people often feel are:

• Code ownership improves quality of code because developers would not want their code to be of bad quality. How can a methodology which eliminates code ownership produce good quality code?

• Why have 2 people work on a task, when one person can do it in the same time?

• Developers will not want to work together because of ego clashes.

The above reservations may initially seem very intuitive and correct, but in reality studies have shown them to be incorrect. Let us take each reservation separately and analyze it.

Code ownership improves quality of code

It is true that when developers own the code they write, they try to make it as good as possible, because after all, it is their reputation at stake. However individual code ownership diminishes the chances of peer review. Peer review has been found to be very helpful in increasing code quality.

During pair programming the code and design is reviewed immediately. Thus if a developer makes a mistake due to an oversight, it is very likely that his pair will point it out. Also when dealing with a particularly difficult coding or design problem, it has been found that 2 developers will explore a larger solution space and will find a better solution.

Having 2 developers working on a task would be wasting human resources

If we apply simple mathematics here, we can conclude that if 1 person takes 100 hours to code a particular task then 2 people working together on the same terminal and the same task would also take 100 hours, which is actually 200 person hours. Why would we to spend double the time and reduce productivity? Studies have shown that when people program in pairs they actually code faster taking only 15% more time [2]. It has also been shown that the resulting code has 15% fewer bugs.

We all know that if a defect is caught early in the development cycle, the cost of rectifying it is a lot lesser than if they were caught later. In pair programming, since all code is reviewed immediately when it is written, many defects are eliminated almost right away. This results in significant savings in time that would be spent in removing these defects, had they been caught later in the development cycle.

The 15% extra time that the pairs take is more than compensated by the time saved in QA related tasks. The saving can be as much as 60 times the extra time spent due to pairing [3]. The resultant code is also of a significantly higher quality thus increasing the robustness and flexibility of the software.

Developers will not work together because of ego clashes or differing working styles

Most people have their own unique style of coding and approaching a problem. It is felt that pair programming would work well only if both developers had a similar style of working. Studies have found this myth also to be untrue.

Even though people do have their own style of coding and problem solving, most of the time they are not averse to working in pairs. In fact it is a well known adage that ?Two heads are better than one.? When two people work together on solving the same problem they explore a larger solution space enriched by their unique experiences. Most likely they will solve the problem with a more creative and efficient solution.

The fact that developers in a pair bring their experience in the way they work very often results in spontaneous learning. Working in pairs can also be a socially pleasurable activity which helps the team to reduce work related stress.

Other Benefits

Far from being unproductive and difficult to implement, pair programming has yielded several benefits. Some of them include:

1. Economic benefits
2. Work satisfaction
3. Better design quality
4. Increased learning
5. Team building and communication
6. Decreased impact of employee turnover

Here are some things that developers have to say about pair programming:

?The adjustment period from solo programming to collaborative programming was like eating a hot pepper. The first time you try it, you may not like it because you are not used to it. However the more you eat it, the more you like it.?

?As we proceeded with our work, I started to notice that one team consistently produced designs of distinctly better quality than the others. I asked them about this.
They said that they had taken to working together, on both the design and the programming. They found that their designs and programs were better this way. I agreed with them and made it standard for all teams to work in pairs. The design quality is now better?
[From the interview files of A. Cockburn]

?We came up with different ideas about how the design should go and the result of arguing over which one was better often led to a truly superior hybrid design?

?There were times we felt that we would have given up except that we ?tag teamed.? I?d be on the ropes and I?d describe the problem in such a way that he had a valuable insight. Then he?d fight on as long as he could and stop?then ?id have an insight?and so on. I suppose others would call it brainstorming, but it feels different to me.?

Author

Parag Shah graduated from the University of North Carolina at Charlotte with a Masters degree in Computer Science. While he was studying at UNCC, he had the opportunity to work with IBM on a research project on ?software collaboration techniques? for the CIIMPLEX consortium.

Following his graduation Parag worked for an eCRM startup company before returning to India. Since then he has been working as an independent consultant under the commercial name of Adaptive Software Solutions. Parag has offered J2EE consulting and training services to several organizations in India, and is also adjunct faculty at SCIT – Pune. Other activities include publishing a monthly newsletter on Software Design and Processes. Parag brings over 8 years of industry experience in various aspects of software development.

References

1. L. L. Constantine, Constantine on Peopleware, Yourdon Press, Englewood Cliffs, N.J. 1995.
2. Williams, L., et al., Strengthening the case for Pair Programming, in IEEE Software, submitted to IEEE Software. Online at
3. Alistair Cockburn, and Laurie Williams, The costs and benefits of pair programming.