A Pair Programming Experience

Agile methods and extreme programming have risen to the forefront of software management and development interest over the last few years. Two definitions of agile are: (1) able to move quickly and easily, and (2) mentally alert. Both definitions rely on the capabilities of the people within the development process. The "Agile Manifesto" [ Manifesto ] published in Software Development in 2001 created a new wave of interest in the agile philosophy and re-emphasized the importance of people. One of the points highlighted in the Manifesto is "We value individuals and interactions over processes and tools." That does not mean processes and tools are evil. It implies the individuals and interactions (people) are of higher priority than processes and tools. Textbooks [ DeMarco , Weinberg ] have been written to describe the importance of people in these new software development approaches that have demonstrated improved productivity and product quality. "Extreme programming" [ Beck ] is one member covered by the umbrella of agile methods. "Pair programming" [ Williams ] is a major practice [ Beck2 ] of extreme programming.

The official definition of pair programming is two programmers working together, side by side, at one computer collaborating on the same, analysis, design, implementation and test. In other words - two programmers, one pencil.

We have all experienced elements of the pair programming concept in one way or another during our lives. How many times have we been stuck removing an error from a design or program with no success? When everything else failed, we went to our neighbour programmer, the "casual observer", to see if we could get some assistance. While explaining our problem, we have a flash of inspiration, and the problem is quickly solved. How much time did we waste before asking a neighbour for insight? Can we relate this to pair programming?

I was introduced to pair programming indirectly as an undergraduate electrical engineering student in the 1950s. The class and laboratory workload was such that any free time during the 4-year program was more wishful thinking than reality. Working part time made the program even more daunting. Fortunately, two other EE students in the same academic program were struggling with different sets of outside commitments. We decided to work together on homework assignments, lab work and test preparation to lighten the course load. We successfully maintained that approach through the entire program in spite of having been conditioned throughout our lives to perform solitary work. Our educational system does not condone or encourage teamwork. That education philosophy supports individual student evaluation, but works against learning. The teamwork concept became ingrained in my thinking, as well as in my programming and management research activities.

Later, much later, I was asked to find ways to improve programmer productivity in a large software organization. The undergraduate experience led me to propose an experiment in the application of what we called "two-person programming teams." The term pair programming hadn't been coined at that time. The experiment results are the subject of this case study.

Development Task

Problem

A description of the results achieved through the use of pair programming without knowledge of the project or development task underlying the experience would be meaningless. The software to be developed in this project was a multitasking real-time system executive. The product consisted of six independent components containing a total of approximately 50,000 source lines of code. The product contained no reused or COTS ["Commercial, Off-the-Shelf"] components. FORTRAN was the required software development language. The real-time executive was to be used to support the development of a large, complex software system by the developing organization. The development schedule for the executive was critical and short.

Team Composition

The development team consisted of ten programmers with a wide range of experience and a manager. I tend to divide managers into two primary groups: Theory X [ Hersey , McGregor ] and Theory Y. The manager for this task was experienced and from the Theory Y group.

The ten programmers assigned to the executive development had prior experience that ran the gamut from an expert system programmer to a couple of fresh, young college graduates. None of these programmers had any experience working in a team environment. As a collection, I would place them as about average for that development organization.

The manager grouped the programmers into five teams according to their experience level. Each team pair was composed of the most experienced and least experienced programmer of the remaining group. The first team consisted of the expert system programmer and a person who had just returned from a six-year leave of absence. The fifth team consisted of two programmers of near equal capability and experience. These first and fifth programming teams were important in the way they impacted the project. I will address their impacts in the Lessons Learned.

No special changes from normal were made to the development environment. The facilities were essentially 2-person cubicles. The programming pairs were co-located in these cubicles. Each cubicle contained two computer workstations, two desks and a common worktable. The pair programming approach dictated that the pair (two programmers, one pencil) uses only one development terminal located on the common worktable. The second terminal was be used for documentation, etc. not related to the team's assigned development.

One programmer of the pair functioned as the "driver" operating the keyboard and mouse, while the second programmer functioned more as a "navigator" or "co-pilot." The navigator reviewed, in real-time, the information entered by the driver. The roles of the two programmers were not permanent; frequent role changes occurred daily. The navigator was not a passive role at any time.

Results

A Priori

A productivity and error baseline for the project could not be directly obtained for the project individuals, but data was available from past projects that allowed us to project productivity and error averages for the project. The average productivity and error rates in most organizations with consistent management style and processes are near constant and quite predictable. The baseline productivity was determined to be approximately 77 source lines per person-month. The error rate for the development organization was normal for the aerospace industry. The numerical error rate value is not significant for this presentation, and will remain unknown.

Formal design walkthroughs and software inspections were not scheduled for this project. The project would follow a classic waterfall development approach, which is inconsistent with today's agile methods. Formal preliminary and critical design reviews, as well as a final qualification test, were planned. Formal review and test documentation was reduced to essential information; that is, all elements necessary to proceed with the development.

A Posteriori

The productivity achieved in the real-time executive development was 175 source lines per person-month as shown in Table 1. We hoped for a productivity gain of anything greater than 0 percent. Any small gain would have compensated for the two programmers loading on each task. The 127 percent gain achieved was phenomenal and a cause for celebration.

The error analysis showed the project had achieved an error rate that was three orders of magnitude less than normal for the organization. Integration of the first two components (approximately 10,000 source lines) was completed with only two coding errors and one design error. The third component was integrated with no errors. The remaining three components had more errors, but the number of errors for these components was significantly less than normal.

Table 1. Pair programming productivity and error rate gains

The "continuous walkthrough" assumption was demonstrated to be very effective, and more than compensated for the lack of formal walkthroughs. The formal preliminary and critical design reviews, as well as a final qualification test, were effective in keeping the five teams coordinated. Few problems were uncovered in the review and test activities.

After the experiment was completed, the development manager presented the very positive results to the organization's management staff. The project managers' reaction to the results was memorable. They claimed that their senior programmers would quit before they would team with another programmer. The use of pair programmers was never implemented in that organization.

Lessons Learned

Several positive and some negative characteristics were observed during the pair programming experiment. In general the attributes of the college experience were exhibited here. The positive attributes, not necessarily in any order, are as follows:

• Brainstorming - According to the programmers, active real-time produced higher quality designs than would have been achieved working alone. Little time was lost optimizing code with more than one brain working.

• Continuous design walkthrough - The design and code were reviewed in real-time by both programmers who ultimately produced fewer errors in each team product. Classic walkthroughs and inspections are, whether we like it or not, somewhat adversarial. The continuous walkthroughs within the team were more positive and supportive.

• Focused energy - The individual teams appeared to be more focused in their activities. The highly visible aspect of this attribute was the programmers took fewer breaks for restrooms, coffee, outside discussions, etc.

• Mentor - When we started work in this industry, we were usually told about on-the-job training that never materialized. Pair programming, when the two programmers were not of the same experience level, provided a craftsman/apprentice relationship that elevated the junior programmer's skill quickly. Conversely, the craftsman's skill is extended by the apprentice's questions and thinking outside of the box.

• Motivation - In general, the programming pairs appeared much more motivated than their single counterparts. The motivation level cannot be solely attributed to the pair concept or the experiment itself. Some of the motivation must be attributed to the project manager. Some has to be attributed to rapid progress and the product quality. One of the Theory Y assumptions is that motivation occurs at the social, esteem and self-actualization levels, as well as physiological and security levels.

• Problem isolation - The time wasted with two pairs of eyes (or brains) is significantly less than the amount of time wasted trying to solve a problem in isolation.

The negative observations cannot be ignored. The important observations, not necessarily in order of importance, are as follows:

• Programming pair of the same experience and capability level is often counter-productive. The most troublesome pairs we dealt with during the experiment were two teams in which both members were near the same capability level. The worst case team consisted of two "prima donna" programmers. The programming pair theoretically has equal responsibility for the team's efforts and product. We found teams functioned more smoothly, in spite of the members equally being driver and navigator, if one member was slightly more capable than the other. I read a statement by a software industry leader that stated hiring software engineers from the top ten percentile of the top ten universities would produce the best software development teams. I cannot imagine the stress that many egos can create on one project. Two strong egos of any caliber on a team create chaos until they recognize the power of two minds.

• Coordination between the five teams would have improved if the teams had been working in a common area. Each team was located in a two-person cubicle, which limited the interaction between the teams. I use the term war room (or skunk works) to describe the ideal open environment, which would be a large area with worktables in the centre and cubicles around the outside.

Some additional characteristics of the successful experiment are worthy of note. First, one of the manager's principal responsibilities was to buffer the teams from outside interference. The manager listed other important responsibilities that included referee (in the case of the prima donnas), arbitrator, coordinator, planner, cheerleader, and supplier of popcorn and other junk food.

Second, project managers must be supportive of the pair programming process. A classic (Theory X) manager observed a programming pair working on a design over a period of time. This manager suggested to their supervisor that one of the two programmers be laid off because only one was doing anything constructive. (The driver always gets the credit.) When the supervisor heard the suggestion, he replied that these programmers were the most productive people in the organization. The manager answered that the programmers keep their office door closed so others would not get the same idea.

Summary and Conclusions

Most managers who have not experienced pair programming reject the idea without trial for one of two reasons. First, the concept appears redundant and wasteful of computing resources. Why would I want to use two programmers to do the work that one can do? How can I justify a 100 percent increase in person-hours to use this development approach? The project cannot afford to waste limited resources.

The second reason is the assumption that programmers prefer to work in isolation. Programmers, like most other people, have been trained to work alone. Yet, according to the 1984 Coding War Games sponsored by the Atlantic Systems Guild, only one third of a programmer's time is spent is isolation; two-thirds of the time is spent communicating with team members. Managers wonder about the adjustments necessary to adjust to another's work habits and programming style. They also worry about ego issues and disagreements about the product's implementation.

This experiment demonstrated strongly that programmers can work together effectively and efficiently to produce a quality product of which both programmers can be proud. Prior programming experience is not an issue. There are situations that initially occur, especially with a team of equal experience and ego, where disagreements over who will be the driver arise. Those situations are generally transient. The benefits listed in the Results Section overwhelmed any personality issues that arose.

The second major benefit demonstrated in this experiment, a three order of magnitude improvement in error rate, is hard to ignore. Repairing defects after developments are much more expensive to fix than uncovering and fixing the defects where they occur. The benefits of developing and delivering a stable product faster, reducing maintenance costs, and gaining customer satisfaction certainly minimizes the risk of using pair programming teams.

This article has been previously published (as follows) and is used by permission of STSC.

Jensen, Randall W., "A Pair Programming Experience," CrossTalk: A Journal of Defense Software Engineering , (Hill AFB, UT: Software Technology Support Center), March 2003

References

[Manifesto] "The Agile Manifesto," Software Development , Vol. 9, No. 8, August, 2001

[DeMarco] DeMarco, T. and T. Lister, Peopleware , (New York: Dorset House Publishers), 1977

[Weinberg] Weinberg, G. M., The Psychology of Computer Programming Silver Anniversary Edition , ((New York: Dorset House Publishers), 1998

[Beck] Beck, K., Extreme Programming Explained: Embracing Change , (Reading, MA: Addison-Wesley),2000

[Williams] Williams, L., R. R. Kessler, W. Cunningham and R. Jeffries, "Strengthening the Case for Pair Programming," IEEE Software , Vol. 17, No. 4, (July/August 2000), pp. 19-25

[Beck2] Beck, K., "Embracing Change with Extreme Programming," Computer , October, 1999, pg.71

[Hersey] Hersey, P. and K. H. Blanchard, Management of Organizational Behavior, Utilizing Human Resources , (Englewood Cliffs, NJ: Prentice-Hall, Inc.), 1977, Theory X assumes: 1. Work is inherently distasteful to most people. 2. Most people are not ambitious, have little desire for responsibility, and prefer to be directed. 3. Most people have little capacity for creativity in solving organizational problems. 4. Most people must be closely controlled and often coerced to achieve organizational objectives. Theory Y assumes: 1. Work is as natural as play, if conditions are favourable. 2. Self-control is often indispensable in achieving organization goals. 3. The capacity for creativity in solving organizational problems is widely distributed in the population. 4. People can be self-directed and creative at work if properly motivated.

[McGregor] McGregor, D., The Human Side of Enterprise, (New York: McGraw-Hill Book Co.), 1960