Best Practices

A Pair Programming Experience

Dr. Randall W. Jensen
Software Technology Support Center
Agile software development methods, including extreme programming, have risen to the forefront of software management and
development interest during the last few years. The “Agile Manifesto” published in 2001 created a new wave of interest in
the agile philosophy and re-emphasized the importance of people, along with the idea of “pair programming.” As defined,
pair programming is two programmers working together, side by side, at one computer collaborating on the same analysis,
design, implementation, and test. I was introduced to teamwork and pair programming indirectly as an undergraduate elec-
trical engineering student in the 1950s. Later in 1975, I was asked to improve programmer productivity in a large software
organization. The undergraduate experience led me to an experiment in pair programming. The very positive results of this
experiment are the subject of the case study in this article.

A gile methods and extreme program-

ming have risen to the forefront of
software management and development
I was introduced to pair programming
indirectly as an undergraduate electrical
engineering student in the 1950s. The class
The experiment results are the subject of
the remainder of this article.

interest during the last few years. Two defi- and laboratory workload were such that any Development Task
nitions of agile are (1) able to move quickly free time during the four-year program was Problem
and easily, and (2) mentally alert. Both defi- more wishful thinking than reality. Working Providing a description of the results
nitions rely on the capabilities of the people part time made the program even more achieved through pair programming with-
within the development process. daunting. Fortunately, two other electrical out knowledge of the project or develop-
The “Agile Manifesto” [1] published in engineering students in the same academic ment task underlying the experience would
Software Development in 2001 created a new program were struggling with different sets be meaningless. The software to be devel-
wave of interest in the agile philosophy and of outside commitments. We decided to oped in this project was a multitasking real-
reemphasized the importance of people. work together on homework assignments, time system executive. The product consist-
One of the points highlighted in the mani- lab work, and test preparation to lighten the ed of six independent components contain-
festo is, “We value individuals and interac- course load. ing a total of approximately 50,000 source
tions over processes and tools.” That does lines of code. The product contained no
not mean processes and tools are evil. It reused or commercial-off-the-shelf compo-
implies that individuals and interactions
(people) are of higher priority than process-
“The second major nents. Fortran was the required software
development language. The real-time execu-
es and tools. benefit demonstrated in tive was to be used to support the develop-
Textbooks [2, 3] describe the impor- ment of a large, complex software system
tance of people in these new software this experiment – a by the developing organization. The devel-
development approaches that have demon- opment schedule for the executive was crit-
strated improved productivity and product three order-of-magnitude ical and short.
quality. Extreme programming (XP) [4] is one
member covered by the umbrella of agile improvement in error Team Composition
methods. Pair programming [5] is a major prac- The development team consisted of 10
tice [6] of XP. The official definition of pair rate – is hard to ignore.” programmers with a wide range of experi-
programming is two programmers working ence and one manager. I tend to divide
together, side by side, at one computer col- We successfully maintained this managers into two primary groups: Theory
laborating on the same analysis, design, approach through the entire program in X1 and Theory Y2 [7, 8]. The manager for
implementation, and test. In other words, spite of having been conditioned through- this task was experienced and from the
consider it like two programmers using one out our lives to perform solitary work. Our Theory Y group.
pencil. educational system does not condone or The 10 programmers assigned to the
We have all experienced elements of the encourage teamwork. That education phi- executive development had prior experi-
pair-programming concept in one way or losophy supports individual student evalua- ence that ran the gamut from an expert sys-
another during our lives. How many times tion, but works against learning. The team- tem programmer to a couple of fresh,
have you been stuck removing an error work concept became ingrained in my young college graduates. None of these
from a design or program with no success? thinking as well as in my programming and programmers had any experience working
When everything else failed, you went to management research activities. in a team environment. As a collection, I
your neighbor programmer, the casual observ- Much later, I was asked to find ways to would place them as about average for that
er, to see if you could get some assistance. improve programmer productivity in a large development organization.
While explaining the problem, you have a software organization. The undergraduate The manager grouped the program-
flash of inspiration, and the problem is experience led me to propose an experiment mers into five teams according to their
quickly solved. How much time did you in the application of what we called two-per- experience level. Each team pair was com-
waste before asking a neighbor for insight? son programming teams. The term pair pro- posed of the most experienced and least
Can you relate this to pair programming? gramming had not been coined at that time. experienced programmer of the remaining

22 CROSSTALK The Journal of Defense Software Engineering March 2003

 A Pair Programming Experience

group. The first team consisted of the

Topic Historical Pair Results Gain
expert system programmer and a person
Productivity (lines/person-month) 77 175 127 percent
who had just returned from a six-year leave Error Rate 0.001 x normal
of absence. The fifth team consisted of
two programmers of near equal capability Table 1: Pair Programming Productivity and Error Rate Gains
and experience. These first and fifth pro- A Posteriori ultimately produced fewer errors in each
gramming teams were important in the way The productivity achieved in the real-time team product. Classic walkthroughs and
they impacted the project. I will address executive development was 175 source lines inspections are, whether we like it or
their impacts in the Lessons Learned sec- per person-month as shown in Table 1. We not, somewhat adversarial. The continu-
tion of this article. hoped for a productivity gain of anything ous walkthroughs within the team were
No special changes from normal were greater than 0 percent. Any small gain more positive and supportive.
made to the development environment. would have compensated for the two pro- • Focused Energy. The individual teams
The facilities were essentially two-person grammers loading on each task. The 127 appeared to be more focused in their
cubicles. The programming pairs were col- percent gain achieved was phenomenal and activities. The highly visible aspect of
located in these cubicles. Each cubicle con- a cause for celebration. this attribute was that programmers
tained two computer workstations, two The error analysis showed the project took fewer breaks for restrooms, coffee,
desks, and a common worktable. The pair- outside discussions, etc.
had achieved an error rate that was three
programming approach dictated that the • Mentor. When we started work in this
orders of magnitude less than normal for
pair (remember: two programmers, one industry, we were usually told about on-
the organization. Integration of the first
pencil) use only one development terminal
two components (approximately 10,000 the-job training that never materialized.
located on the common worktable. The
source lines) was completed with only two Pair programming, when the two pro-
second terminal was to be used for docu-
coding errors and one design error. The grammers were not of the same experi-
mentation, etc., not related to the team’s
third component was integrated with no ence level, provided a crafts-
assigned development.
errors. The remaining three components man/apprentice relationship that elevat-
One programmer of the pair func-
tioned as the driver operating the keyboard had more errors, but the number of errors ed the junior programmer’s skill quickly.
and mouse, while the second programmer for these components was significantly less Conversely, the craftsman’s skill is
functioned more as a navigator or co-pilot. than normal. extended by the apprentice’s questions
The navigator reviewed, in real time, the The continuous walkthrough assumption and thinking outside of the box.
information entered by the driver. The was demonstrated to be very effective and • Motivation. In general, the program-
roles of the two programmers were not more than compensated for the lack of for- ming pairs appeared much more moti-
permanent; frequent role changes occurred mal walkthroughs. The formal preliminary vated than their single counterparts. The
daily. The navigator was not a passive role and critical design reviews, as well as a final motivation level cannot be solely attrib-
at any time. qualification test, were effective in keeping uted to the pair concept or the experi-
the five teams coordinated. Few problems ment itself. Some of the motivation
Results were uncovered in the review and test activ- must be attributed to the project manag-
A Priori ities. er. Some must be attributed to rapid
Project individuals could not directly After the experiment was completed, progress and the product quality. One of
obtain a productivity and error baseline for the development manager presented the the Theory Y assumptions is that moti-
the project, but data was available from very positive results to the organization’s vation occurs at the social, esteem, and
past projects that allowed them to project management staff. The project managers’ self-actualization levels, as well as physi-
productivity and error averages for the reaction to the results was memorable – ological and security levels.
project. The average productivity and error they claimed that their senior programmers • Problem Isolation. The time wasted
rates in most organizations with consistent would quit before they would team with with two pairs of eyes (or brains) was
management style and processes are near another programmer. The use of pair pro- significantly less than the amount of
constant and quite predictable. The base- grammers was never implemented in that time wasted trying to solve a problem in
line productivity was determined to be organization. isolation.
approximately 77 source lines per person- Conversely, the negative observations
month. The error rate for the development Lessons Learned cannot be ignored. The important observa-
organization was normal for the aerospace Several positive and some negative charac- tions, not necessarily in order of impor-
industry. The numerical error rate value is teristics were observed during the pair-pro- tance, are as follows:
not significant for this presentation, and gramming experiment. In general, the • Counter-Productivity. Pairing pro-
will remain unknown. attributes of the college experience were grammers of the same experience and
Formal design walkthroughs and soft- exhibited here. The positive attributes, not capability level is often counter-produc-
ware inspections were not scheduled for necessarily in any order, are as follows: tive. The most troublesome pairs we
this project. It would follow a classic water- • Brainstorming. According to the pro- dealt with during the experiment were
fall development approach, which is incon- grammers, active real-time collaboration two teams in which both members were
sistent with today’s agile methods. Formal produced higher quality designs than near the same capability level. The
preliminary and critical design reviews, as would have been achieved working worst-case team consisted of two prima
well as a final qualification test were alone. Little time was lost optimizing donna programmers. The programming
planned. Formal review and test documen- code with more than one brain working. pair theoretically has equal responsibility
tation were reduced to essential informa- • Continuous Design Walkthrough. for the team’s efforts and product. We
tion; that is, all elements necessary to pro- The design and code were reviewed in found teams functioned more smoothly,
ceed with the development. real time by both programmers who in spite of the members equally being

March 2003 www.stsc.hill.af.mil 23

Best Practices

driver and navigator, if one member have been trained to work alone. Yet Enterprise. New York: McGraw-Hill,
was slightly more capable than the according to the 1984 Coding War Games 1960.
other was. I read a statement by a soft- sponsored by the Atlantic Systems Guild,
ware industry leader that stated hiring only one-third of a programmer’s time is Note
software engineers from the top 10 spent in isolation; two-thirds of the time is 1. Theory X assumes the following: (1)
percentile of the top 10 universities spent communicating with team members. Work is inherently distasteful to most
would produce the best software devel- Managers wonder about the necessary people. (2) Most people are not ambi-
opment teams. I cannot imagine the adjustments to another’s work habits and tious, have little desire for responsibility,
stress that many egos can create on programming style. They also worry about and prefer to be directed. (3) Most peo-
one project. Two strong egos of any ego issues and disagreements about the ple have little capacity for creativity in
caliber on a team create chaos until product’s implementation. solving organizational problems. (4)
they recognize the power of two This experiment demonstrated strong- Most people must be closely controlled
minds. ly that programmers can work together and often coerced to achieve organiza-
• Common Area. Coordination effectively and efficiently to produce a tional objectives.
between the five teams would have quality product of which both program- 2. Theory Y assumes the following: (1)
improved if the teams had been work- mers can be proud. Prior programming Work is as natural as play, if conditions
ing in a common area. Each team was experience is not an issue. There are initial are favorable. (2) Self-control is often
located in a two-person cubicle, which situations, especially with a team of equal indispensable in achieving organization
limited the interaction between the experience and ego, where disagreements goals. (3) The capacity for creativity in
teams. I use the term war room (or arise over who will be the driver. Those sit- solving organizational problems is wide-
skunk works) to describe the ideal uations are generally transient. The bene- ly distributed in the population. (4)
open environment, which would be a fits listed in the results section over- People can be self-directed and creative
large area with worktables in the center whelmed any personality issues that arose. at work if properly motivated.
and cubicles around the outside. The second major benefit demonstrat-
Some additional characteristics of the ed in this experiment – a three order-of- About the Author
successful experiment are noteworthy. magnitude improvement in error rate – is
First, one of the manager’s principle hard to ignore. Repairing defects after Randall W. Jensen,
responsibilities was to buffer the teams developments is much more expensive Ph.D., is a consultant
from outside interference. The manager than uncovering and fixing the defects for the Software
listed other important responsibilities that where they occur. The benefits of devel- Technology Support
included referee (in the case of the prima oping and delivering a stable product Center, Hill Air Force
donnas), arbitrator, coordinator, planner, faster, reducing maintenance costs, and Base, with more than
cheerleader, and supplier of popcorn and gaining customer satisfaction certainly 40 years of practical experience as a
other junk food. minimize the risk of using pair-program- computer professional in hardware
Second, project managers must be sup- ming teams.◆ and software development. He devel-
portive of the pair programming process. oped the model that underlies the Sage
A classic (Theory X) manager observed a References and the GAI SEER-SEM software
programming pair working on a design 1. The Agile Alliance. “The Agile cost and schedule estimating systems.
over a period of time. This manager sug- Manifesto.” Software Development 9.8
Jensen received the International
gested to their supervisor that one of the (Aug. 2001).
two programmers be laid off because only 2. DeMarco, Tom, and T. Lister. Society of Parametric Analysts
one was doing anything constructive. (The Peopleware. New York: Dorset House Freiman Award for Outstanding
driver always gets the credit.) When the Publishers, 1977. Contributions to Parametric Estima-
supervisor heard the suggestion, he 3. Weinberg, G. M. The Psychology of ting in 1984. He has published several
replied that these programmers were the Computer Programming Silver Anni- computer-related texts, including
most productive people in the organiza- versary Edition. New York: Dorset “Software Engineering,” and numer-
tion. The manager then asked that the House Publishers, 1998. ous software and hardware analysis
programmers keep their office door closed 4. Beck, Kent. Extreme Programming papers. He is currently preparing
so others would not get the same idea. Explained: Embracing Change. “Extreme Software Estimating” for
Reading, MA: Addison-Wesley, 2000. Prentice-Hall, Inc. Dr. Jensen has a
Summary 5. Williams, L., R. R. Kessler, W. bachelor’s of science degree in electri-
Most managers who have not experienced Cunningham, and R. Jeffries. cal engineering, a master’s of science
pair programming reject the idea without “Strengthening the Case for Pair
degree in electrical engineering, and a
trial for one of two reasons. First, the con- Programming.” IEEE Software 17.4
cept appears redundant and wasteful of (July/Aug. 2000): 19-25. doctorate in electrical engineering
computing resources. Why would I want 6. Beck, Kent. “Embracing Change with from Utah State University.
to use two programmers to do the work Extreme Programming.” Computer
Software Technology Support Center
that one can do? How can I justify a 100 Oct. 1999: 71.
percent increase in person-hours to use 7. Hersey, P., and K. H. Blanchard. 7278 4th St.
this development approach? The project Management of Organizational Be- Bldg. 100 G58
cannot afford to waste limited resources. havior, Utilizing Human Resources. Hill AFB, UT 84056
The second reason is the assumption Englewood Cliffs, NJ: Prentice-Hall, Phone: (801) 775-5733
that programmers prefer to work in isola- 1977. Fax: (801) 777-8069
tion. Programmers, like most other people, 8. McGregor, D. The Human Side of E-mail: [email protected]

24 CROSSTALK The Journal of Defense Software Engineering March 2003