ArticlePDF Available

The Costs and Benefits of Pair Programming


Abstract and Figures

Pair or collaborative programming is where two programmers develop software side by side at one computer. Using interviews and controlled experiments, the authors investigated the costs and benefits of pair programming. They found that for a development-time cost of about 15%, pair programming improves design quality, reduces defects, reduces staffing risk, enhances technical skills, improves team communications and is considered more enjoyable at statistically significant levels.
Content may be subject to copyright.
Page 1
The Costs and Benefits of Pair Programming
Alistair Cockburn
Humans and Technology
7691 Dell Rd
Salt Lake City, UT 84121, USA 801.947.9277
Laurie Williams
University of Utah Computer Science
50 S. Central Campus #3190
Salt Lake City, UT 84112, USA 435.649.7931
“Only if the various principles - names,
definitions, intimations and perceptions - are
laboriously tested and rubbed one against the
other in a reconciliatory tone, without ill will
during the discussion, only then will insight and
reason radiate forth in each case, and achieve
what is for man the highest possible force...”
“Knowledge is commonly socially constructed,
through collaborative efforts toward shared
objectives or by dialogues and challenges
brought about by differences in persons'
perspectives." -Salomon [1]
Pair or collaborative programming is where two
programmers develop software side by side at
one computer. Using interviews and controlled
experiments, the authors investigated the costs
and benefits of pair programming. They found
that for a development-time cost of about 15%,
pair programming improves design quality,
reduces defects, reduces staffing risk, enhances
technical skills, improves team communications
and is considered more enjoyable at statistically
significant levels.
pair programming, collaborative programming,
extreme programming, code reviews, people
factors, collaborative programming
When pair programming, two programmers work
collaboratively on the same algorithm, design or
programming task, sitting side by side at one
computer. This practice has been nominated
several times in the last decades as an improved
way of developing software [2] [3].
However, convention speaks against having two
people work together to develop code -- having
“two do the work of one”, as some people see it.
Managers view programmers as a scarce
resource, and are reluctant to "waste" such by
doubling the number of people needed to
develop a piece of code.
Programming has traditionally been taught
and practiced as a solitary activity.
Many experienced programmers are very
reluctant to program with another person.
Some say their code is "personal," or that
another person would only slow them down.
Others say working with a partner will cause
trouble coordinating work times or code
At the same time:
Several well-respected programmers prefer
working in pairs, making it their preferred
programming style [2] [3].
Seasoned pair programmers describe working
in pairs as "more than twice as fast" [3].
Qualitative evidence suggests the resulting
design is better, resulting in simpler code,
easier to extend.
Even relative novices contribute to an expert's
programming, according to interviews.
This raises some provocative questions. Is pair
programming really more effective than solo
programming? What are the economics? What
about the people factor - enjoyment on the job?
Based on recent interest in pair programming, the
authors examined interview and experimental
data to understand the costs and benefits of
practice. This paper presents the results of that
Page 2
investigation. Previous publications [4] [5] [6]
have demonstrated that pair programming is
beneficial. The purpose of this paper is to re-
examine these results and to further explain why
pair programming is beneficial.
The following excerpt comes from an
experienced programmer describing his
organization’s first venture into pair
programming. It reveals many features of the pair
programming experience, as will be discussed in
this paper.
In early December my team began a high-risk
activity: it involved touching just about every file,
merging the code together, and trying to keep
everything working. Furthermore, one tree involved
fairly deep rearchitecture. So the merge would be
composed of both utter tedium and massive thought
The staff agreed with my points that pair
- Should significantly reduce the risk of subtle
errors that would make debugging excruciating;
- Would give us a much broader code review than
we'd ever had; and
- Would provide an opportunity to communicate
knowledge between coders.
For the first few weeks, things didn't work out as
envisioned. Instead of doing side-by-side pair
programming, the first few people did what I called
"partner programming": they coded individually for
awhile, and then reviewed the changes with their
partner before checking-in the modifications. They
reported that they were catching errors early. This
was encouraging, but I was disappointed that they
weren't working together consistently.
But about four months into the merge, I began to
notice that things were changing. One pair in
particular spent their whole day together, doing
honest-to-goodness pair programming, and the
other two pairs were getting much closer to that
ideal. In discussions it was clear that they knew why
the change was happening. It simply worked better!
They discovered that it took longer to work
independently and then review the changes, since
the review process involved teaching your partner
everything you had learned in making the changes.
And that took almost as long as making the
changes to begin with. By working together they
could avoid "doing it twice", the coding went faster
due to the two-brain effect, and they were much
more confident in the correctness of the results.
When we finally made it to the first checkpoint
application, we zoomed through QA with hardly a
hitch. Everyone, myself included, was amazed that
it didn't take weeks to debug, especially given that
one of the trees had recently spent SIX WEEKS in
QA hell. It was obvious that the pairs had
dramatically reduced the defect rate.
As the merge progressed the pairs worked together
even more closely.
... As each subsystem was complete the pairs
would get rearranged based on knowledge of the
next task. This slowed things down because the
new pairs would have to spend time getting in
phase with one another before working effectively.
But by August the pairs were fairly well cemented,
to the point where they would routinely speak for
each other in our twice-weekly team meetings.
Subsequent releases, both internal and external,
went smoothly and we rarely hit massive show-
stopper bugs. The continual review caught many
serious issues midstream, including some major
design problems that hadn't been noticed before.
I wasn't involved in a pair until fairly late in the
game. Once my partner and I synchronized our
brains, it was a great experience.
He was relatively junior, but he asked the right
questions and, by struggling for answers, we usually
forced ourselves to discover the best solution to
each problem.
... The team members decided to do it for
themselves. None of my pontification had as much
effect as experience.
We explore eight paths of software engineering
and organizational effectiveness. Surprisingly,
all paths point to pair programming. These
investigative paths are briefly described:
Economics. A recent controlled experiment [4]
found only a small development cost for adding
the second person. However, the resulting code
also had fewer defects. The defect removal
savings should more than offsets the development
cost increase.
Satisfaction. People working in pairs found the
experience more enjoyable than working alone.
Design quality. The study [4] also found that the
pairs produced shorter programs than their solo
peers, indicating superior designs. Interviewees
Page 3
made the same comments.
Continuous Reviews. Pair programming’s
shoulder-to-shoulder technique serves as a
continual design and code review, leading to
most efficient defect removal rates.
Problem solving. Interview participants
constantly refer to the team's ability to solve
"impossible" problems faster.
Learning. Pair programmers repeatedly cite how
much they learn from each other.
Team Building and Communication. Interview
participants describe that people learn to discuss
and work together. This improves team
communication and effectiveness.
Staff and Project Management. Since multiple
people have familiarity with each piece of code,
pair programming reduces staff-loss risk.
In this paper, each of these investigative paths
will be further discussed -- reviewing the
supporting statistical and interview data and
highlighting the costs and the benefits.
The affordability of pair programming is a key
issue. If it is much more expensive, managers
simply will not permit it. Skeptics assume that
incorporating pair programming will double code
development expenses and critical manpower
needs. Along with code development costs,
however, other expenses, such as quality
assurance and field support costs must also be
considered. IBM reported spending about $250
million repairing and reinstalling fixes to 30,000
customer-reported problems [7]. That is over
$8,000 for each defect!
In 1999, a controlled experiment run by the
second author at the University of Utah
investigated the economics of pair programming.
Advanced undergraduates in a Software
Engineering course participated in the
experiment. One third of the class coded class
projects as they had for years – by themselves.
The rest of the class completed their projects with
a collaborative partner. The results of how much
time the students spent on the assignments are
shown below in Figure 1. After the initial
adjustment period in the first program (the
“jelling” assignment), together the pairs only
spent about 15% more time on the program than
the individuals [4]. Development costs certainly
do not double with pair programming!
Relative Time: One Individual vs Two
Program 1 Program 2 Program 3
One Individual Two Collaborators
Figure 1: Programmer Time
Significantly, the resulting code has about 15%
fewer defects [4]. (These results are statistically
significant.) Figure 2 shows the post-
development test cases the students passed for
each program – essentially the percentage of the
instructor’s test cases passed.
Post Development Test Cases Passed
Program 1 Program 2 Program 3
Individuals Collaborators
Figure 2: Code Defects
The initial 15% increase in code development
expense is recovered in the reduction in defects,
as the following example illustrates. Let a
program of 50,000 lines of code (LOC) be
developed by a group of individual programmers
and by a group of collaborative programmers. At
a typical rate of 50 LOC/hour, the individuals
will develop this code in 1000 hours. It will take
the pairs 15% longer or 1150 hours -- a cost of
150 hours. Based on representative statistics
reported in [7], programmers inject 100 defects
per thousand lines of code. A thorough
development process removes approximately
Page 4
70% of these defects. Therefore, the individuals
would be expected to have 1,500 defects
remaining in their program; collaborators would
have 15% less or 1,275 – 225 less defects.
In some organizations, developers’ code is passed
to a test or quality assurance department, which
finds and fixes many of the remaining defects.
Typically, in systems test it takes between four
[7] and 16 [8] hours per defect. Using a fairly
conservative factor of 10 hours/defect, if testing
finds these “extra” 225 defects they will spend
2,250 hours – fifteen times more than the
collaborators “extra” 150 hours!
If the program is sent directly to a customer
instead of a test department, pair programming is
even more favorable. Industry data reports that
between 33 and 88 hours are spent on each defect
found in the field [7]. Using a fairly conservative
factor of 40 hours/defect, if the customer is
plagued by these “extra” 225 defects, field
support will spend 9,000 hours – sixty times
more than the collaborators “extra” time!
Doubtlessly, pair programming can be justified
on purely economic grounds. But there are more
aspects to consider.
If pair programming is not satisfying,
programmers won't practice it.
Many programmers are initially skeptical, even
resistant, to programming with a partner. It takes
the conditioned solitary programmer out of their
“comfort zone.” One programmer wrote,
“The adjustment period from solo programming to
collaborative programming was like eating a hot
pepper. The first time you try it, you might not like it
because you are not used to it. However, the more
you eat it, the more you like it.”
In statistically significant results, pair
programming teams who had earlier programmed
alone reported that they enjoyed pair
programming more and that they were more
confident in their programs than when they
programmed alone (as the defect rates show they
are entitled to be). The graph (Figure 3) shows
results of anonymous surveys of professional pair
programmers and of student pair programmers at
the University of Utah. Most of the programmers
enjoyed programming collaboratively.
ENJOY the work more because of Pair
Agree Disagree
Figure 3: Pair Enjoyment
A programmer comments,
“It is psychologically soothing to be sure that that no
major mistakes had been made . . . I find it
reassuring to know that [partner] is constantly
reviewing my code while I drive. I can be sure I had
done a good job if someone else I trust had been
watching and approved.”
Another says,
“It’s nice to celebrate with somebody when
something works.”
Students prefer the 15% overhead
In the study previously discussed, the class was
divided into two groups: an “individual” group in
which solo programmers did all programming,
and a “collaborative” group in which all
programming was done in pairs. Each
programming assignment cycle, the individuals
were given one program to complete while the
pairs were given two programs to complete.
After several programming cycles, one pair
complained that this arrangement was unfair.
They felt they had to work harder than the
individuals during each cycle. The instructor
suggested that the students split up and work as
solo programmers as part of the “individual”
group so the would no longer feel they were
being unjustly overworked. Both students
rejected this offer almost instantaneously. They
did not complain about the "unjustness" of the
additional workload again.
We feel that this is a strong indicator of the
satisfaction of pair programming.
Page 5
The following comments came from a team lead
who had never heard of pair programming. He
described why all of his designer-programmers
working together at the same terminal.
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]
In 1991 Nick Flor, a masters student of Cognitive
Science, reported on distributed cognition in a
collaborative programming pair he studied.
Distributed cognition is a field of cognitive
science based on the belief that “Anyone who has
closely observed the practices of cognition is
struck by the fact that the “mind” rarely works
alone. The intelligences revealed through these
practices are distributed – across minds, persons,
and the symbolic and physical environment [1].”
Flor recorded via video and audiotape the
exchanges of two programmers working together
on a software maintenance task. In [9], he
correlated specific verbal and non-verbal
behaviors of the two under study with known
distributed cognition theories. One of these
theories is “Searching Through Larger Spaces of
“A system with multiple actors possesses greater
potential for the generation of more diverse plans
for at least three reasons: (1) the actors bring
different prior experiences to the task; (2) they may
have different access to task relevant information;
(3) they stand in different relationships to the
problem by virtue of their functional roles. . . An
important consequence of the attempt to share
goals and plans is that when they are in conflict, the
programmers must overtly negotiate a shared
course of action. In doing so, they explore a larger
number of alternatives than a single programmer
alone might do. This reduces the chances of
selecting a bad plan. [9]"
A pair programmer's description matches Flor’s:
We often 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.
In the quantitative study at the University of
Utah, the pairs not only completed their programs
with superior quality, but they consistently
implemented the same functionality as the
individuals in fewer lines of code. Details are
shown in Figure 4. We believe this is an
indication that the pairs had better designs.
Lines of Code
Program 1 Program 2 Program 3
Individuals Collaborators
Figure 4
Inspections were introduced more than twenty
years ago as a cost-effective means of detecting
and removing defects from software. Results
[10] from empirical studies consistently profess
the effectiveness of reviews. Even still, most
programmers do not find inspections enjoyable or
satisfying. As a result, inspections are often not
done if not mandated, and many inspections are
held with unprepared inspectors.
Despite a consistent stream of positive findings
over 20 years, industry adoption of inspection
appears to remain quite low, although no definite
data exists. For example, an informal USENET
survey we conducted found that 80% of 90
respondents practiced inspection irregularly or not
at all. [11]
The theory on why inspections are effective is
based on the prominent knowledge that the
earlier a defect is found in a product, the cheaper
it is to fix the defect. Many sources, including
[8] state that it is ten times more expensive to
remove a defect for each additional process step.
This exponential cost growth is easy to
understand. During an inspection, a programmer
might say, “The 'if' statement starting on line 450
Page 6
should also have an 'else' clause.” The
programmer marks the listing and promptly
makes the change at their computer. However, if
the software is already in the field, a customer
makes an irate call to the software shop, “It’s
Christmas Eve, and all of my cash registers just
crashed. I can’t sell anything!”
In the first case, the programmer looks directly at
the problem that was just identified to them. In
the second case, the field maintenance team must
work to translate the symptom (all the cash
registered crashed) back to the problem (which
exact line(s) of code caused the crash). It is easy
to see why the translation of the symptom back to
the problem costs exponentially more than direct
problem identification. With pair programming,
this problem identification occurs on a minute-
by-minute basis. These continual reviews not
only outperform formal reviews in their defect
removal speed, but they also eliminate the
programmer’s distaste for reviews.
The following, sardonically worded description
from a senior (originally skeptical) programmer
shows how pairing with even a novice
contributed to his programming.
I was sitting with one of the least-experienced
developers, working on some fairly straightforward
task. Frankly, I was thinking to myself that with my
great skill in Smalltalk, I would soon be teaching this
young programmer how it’s really done.
We hadn’t been programming more than a few
minutes when the youngster asked me why I was
doing what I was doing. Sure enough, I was off on a
bad track. I went another way. Then the
whippersnapper reminded me of the correct method
name for whatever I was mistyping at the time.
Pretty soon, he was suggesting what I should do
next, meanwhile calling out my every formatting
error and syntax mistake.
[-Ron Jeffries, from [4]]
A final benefit of code reviews is that reviewers
learn new coding idioms and language features,
as well as more about the system.
The continuous reviews of collaborative
programming create a unique educational
capability, whereby the pairs are endlessly learning
from each other. “Indeed, review has a unique
educational capability: The process of analyzing
and critiquing software artifacts produced by others
is a potent method for learning about languages,
design techniques, application domains, and so
forth. [11].”
In keeping with the known characteristics of code
reviews, we find practitioners citing:
Mistakes are found as they are entered, saving
even the cost of compilation, and providing
the economic benefit of early defect
identification and removal.
Coding standards are followed more
accurately with the peer pressure to do so.
Team members learn to talk together and
work together.
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 I’d have an insight . . .
and so on. I suppose others would call it
brainstorming, but it feels different to me.
[-David Wagstaff, Salt Lake City]
Pair relaying is our name for the effect Wagstaff
describes. Indeed, pairs consistently report that
they solve problems faster, and that it is different
from improving design quality, or detecting
typing errors, or brainstorming. By "problem
solving", we refer to when the two are puzzled as
to why something doesn't work as expected, or
simply can't figure out how to go forward.
In interviews and in off-hand remarks,
practitioners describe contributing their
knowledge to the best of their abilities, in turn.
They share their knowledge and energy (and also
brainstorming) in turn, chipping steadily away at
the problem.
Combining brainstorming and pair relaying is
powerful. One seasoned programmer wrote,
I have found that, after working with a partner, if I go
back to working alone, it is like part of my mind is
gone. I find myself getting confused about things.
Knowledge is constantly being passed between
partners, from tool usage tips (even the mouse),
to programming language rules, design and
programming idioms, and overall design skill.
Learning happens in a very tight apprenticeship
Page 7
mode. The partners take turns being the teacher
and the taught, from moment to moment. Even
unspoken skills and habits cross partners.
Line of sight learning in apprenticeships
[12] discusses apprenticeship case studies. These
studies range from tailors to flag signalmen in the
U.S. Navy to butchers in modern supermarkets.
The book is subtitled "legitimate peripheral
participation" to highlight three key aspects of
apprenticeship: that the novice actively
participates; that the novice have legitimate work
to do; and that the novice works on the periphery,
steadily moving toward some higher rank. The
novice's work is initially simple and non-critical.
Later work is more critical.
One of the most distinctive characteristics they
note of successful apprenticeship environments is
that the novice work in a "line of sight" of the
expert, that expertise is transmitted, in part,
through the ongoing visual (and auditory) field.
They describe successful apprenticeship learning
in both tailors and Navy signalmen where “line of
sight” is available. The beginner explicitly picks
up skills from hearing and/or seeing the expert.
The most interesting of the case studies, for this
discussion, is that of the butchers in
supermarkets. They did not have line of sight
access to their local expert. The beginners were
given simple cuts to perform, but did not have a
way to learn how to do more difficult cuts, which
were being done by the senior butcher in another
room. Lave and Wenger present this as a
situation in which apprenticeship learning does
not happen.
It should be obvious that most project
programming environments match the butcher
situation, not the tailor or signalmen situation.
Indeed, we have found it extremely difficult to
set up programming environments in which line-
of-sight and line-of-hearing from expert to novice
can be accommodated. The novice programmer
generally sits in their workspace working on
simple code; the expert sits in their own
workspace creating complex code and making
architectural decisions. Pair programming makes
a better apprenticeship situation.
Expert In Earshot
The first author obtained a project management
pattern from a set of workshops with 10 senior
project managers. The full pattern, listed in the
Appendix, includes examples and caveats; it is
summarized as:
Use Expert In Earshot when novices are not
learning good techniques and habits very well, but
you don't want to turn the expert into a full-time
teacher. Put the expert or leader in the same
workspace as the more novice workers, so that the
novices can learn by watching and listening, while
the expert does his or her usual work. Novices will
pick up expertise and (hopefully good) habits from
the expert. (Your expert will be disturbed more
often, so you will have to set up ways to create
personal quiet time.)
Note the overlap with the apprenticeship studies.
It is significant that this pattern had to be
accepted by all 10 senior project managers, since
they were going to apply it within their company.
Pair programming is an example of both Expert
In Earshot and of legitimate peripheral
participation, with line-of-sight/hearing access.
We can expect, therefore, that the learning that
occurs in pair programming is more significant
than merely learning new tool usage or
programming language idioms. This expectation
matches off-hand reports from practitioners.
Statistical confirmation
Pair programming was used exclusively in a web
programming class at the University of Utah,
taught by the second author. The class consisted
of 20 juniors and seniors, familiar with
programming, but not with web programming
languages and tools. The majority of the students
had only used WYSIWYG web page editors prior
to taking the class. During the eleven-week
semester, the students learned advanced HTML,
JavaScript, VBScript, Active Server Page
Scripting, Microsoft Access/SQL and some
ActiveX commands. In many cases, they had to
intertwine statements from all these languages in
one program listing.
Unusual for such students, they produced their
programs with minimal questions of the teaching
staff. The students were queried about the
reasons for their independence in an anonymous
Page 8
survey on the last day of class.
74% wrote “between my partner and me, we
could figure everything out.”
84% of the class agreed with the statement “I
learned Active Server Pages faster and better
because I was always working with a
We would attribute part of that result to enhanced
problem solving in pairs, as described above, and
part to enhanced pair learning.
When I arrived, I saw a disheartening sight: Bill
didn't have a team; he had a random collection of
six bright, talented individuals who didn't work
together. They didn't sit near each other. They didn't
even like each other. Here is a scene from a weekly
staff meeting
'Let's talk about pair programming. (benefits of pair
programming enumerated) <pause> Therefore, pair
programming is mandatory. All production code
must be written with a partner present.'
<An awkward silence descends. Furtive eye
glances are exchanged.>
'I don't think that's going to work. What if I need to
write code and my partner isn't available?'
'Then you find someone else. One of our goals is to
spread the knowledge around.'
'What if there's no-one else around?'
'If I'm available, I'd be glad to work with you. If there
really is nobody around, push your keyboard away
and wait.'
<Stunned silence >
Some of the first paired sessions went smoothly.
Other sessions were awkward. Communication
was serial and parsimonious. I handheld these
guys by becoming a third wheel. I encouraged the
developers to think out loud (what Ward
Cunningham calls reflective articulation). This did
the trick. They actually began to work together, not
just take turns coding.
After about a week, I noticed a remarkable
phenomenon. The developers were talking to each
other. As people. You really would have to have
been there at the beginning to appreciate this.
Anyway, I noticed them having real conversations.
And laughing. They actually began to enjoy and
trust each other.
Within several weeks, they became a real team."
[from the interview files of A. Cockburn]
The Psychology of Computer Programming [13]
and Peopleware [14], written 20 and 30 years
ago, respectively, still have not been replaced on
the topic of teamwork. More recently, eXtreme
Programming [2], the Crystal Light
methodologies [15] and Adaptive Software
Engineering [16] have strengthened attention
given to team building and communication. In
[17], Cockburn goes farther, and argues that these
are first-order project drivers, not side issues.
Pair programming contributes in three ways.
People learn to work together, as illustrated in the
above quote. In the University of Utah study,
none of the 14 pairs ran into an insurmountable
personality clash. In industry, off-hand
comments indicate personality clashes
occasionally happen, perhaps because there is not
sufficient pressure or motivation for the people to
learn to work together. Interviews with people
who have persevered, however, reveal a pattern
similar to, but not as extreme as the one above.
Often, by having to work together, people learn
to work together.
Learning to work together means that the people
on the team will share both problems and
solutions more quickly, and be less likely to have
hidden agendas from each other. Teamwork is
If the pair can work together, then they learn
ways to communicate more easily and they
communicate more often. This raises the
communication bandwidth and frequency within
the project, increasing overall information flow
within the team. Rotating partners increases the
overall information flow farther.
All of these are likely to increase team
effectiveness, and, indeed, this is what pair
programming teams report. We know of no
statistical study of these effects.
Project management benefits from improved staff
skills and reduced staff risk.
The company and the project team both benefit
from the increased learning. Over the course of
the project, the skills of the team members
increase, in programming and in software design.
Page 9
The risk from losing key programmers is
reduced, because there are multiple people
familiar with each part of the system. This is
referred to as the "truck number" in some circles:
"How many or few people would have to be hit
by a truck (or quit) before the project is
incapacitated?" The worst answer is "one."
Having knowledge dispersed across the team
increases the truck number, and project safety.
The significant benefits of pair programming are
many mistakes get caught as they are being
typed in rather than in QA test or in the field
(continuous code reviews);
the end defect content is statistically lower
(continuous code reviews);
the designs are better and code length shorter
(ongoing brainstorming and pair relaying);
the team solves problems faster (pair
the people learn significantly more, about the
system and about software development (line-
of-sight learning);
the project ends up with multiple people
understanding each piece of the system;
the people learn to work together and talk
more often together, giving better information
flow and team dynamics;
people enjoy their work more.
The development cost for these benefits is not the
100% that might be expected, but is
approximately 15%. This is repaid in shorter and
less expensive testing, quality assurance, and
field support.
1. Salomon, G., Distributed Cognitions: Psychological
and educational considerations. Learning in doing:
Social, cognitive, and computational perspectives, ed.
R. Pea and J.S. Brown. 1993, Cambridge: Cambridge
University Press.
2. Constantine, L.L., Constantine on Peopleware.
Yourdon Press Computing Series, ed. E. Yourdon.
1995, Englewood Cliffs, NJ: Yourdon Press.
3. Beck, K., Extreme Programming Explained: Embrace
Change. 2000, Reading, Massachusetts: Addison-
4. Williams, L., et al., Strengthening the Case for Pair-
Programming, in IEEE Software. submitted to IEEE
Software. Online at
5. Williams, L.A. and R.R. Kessler. The Collaborative
Software Process. in International Conference on
Software Engineering 2000. submitted for
consideration. Limerick, Ireland. Online at
6. Nosek, J.T., The Case for Collaborative Programming,
in Communications of the ACM. 1998. p. 105-108.
7. Humphrey, W.S., A Discipline for Software
Engineering. SEI Series in Software Engineering, ed.
P. Freeman, Musa, John. 1995: Addison Wesley
Longman, Inc.
8. Humphrey, W.S., Introduction to the Personal
Software Process. 1997: Addison-Wesley.
9. Flor, N.V. and E.L. Hutchins. Analyzing Distributed
Cognition in Software Teams: A Case Study of Team
Programming During Perfective Software
Maintenance. in Empirical Studies of Programmers:
Fourth Workshop. 1991: Ablex Publishing
10. Fagan, M.E., Advances in software inspections to
reduce errors in program development. IBM Systems
Journal, 1976. 15: p. 182-211.
11. Johnson, P.M., Reengineering Inspection: The Future
of Formal Technical Review, in Communications of the
ACM. 1998. p. 49-52.
12. Lave, J. and E. Wenger, Situated Learning: Legitimate
peripheral participation. 1991, New York, NY:
Cambridge University Press.
13. Weinberg, G.M., The Psychology of Computer
Programming Silver Anniversary Edition. 1998, New
York: Dorset House Publishing.
14. DeMarco, T. and T. Lister, Peopleware. 1977, New
York: Dorset House Publishers.
15. Cockburn, A., Crystal "Clear": A human-powered
software development methodology for small teams,
Addison-Wesley, 2001, in preparation. Online at
16. Highsmith, J., Adaptive Software Development, Dorset
House, 1999.
17. Cockburn, A., Characterizing People as Non-Linear,
First-Order Components in Software Development, in
International Conference on Software Engineering
2000. submitted for consideration. Limerick, Ireland..
Online as Humans and Technology Technical Report,
TR 99.05,
papers/ nonlinear/nonlinear.htm.
Page 10
Page 11
(slightly abbreviated from
Novices have a hard time developing good habits on their own, so...
Keep an expert within their hearing distance.
(1) Novices are not learning good techniques and habits very well.
(2) Working on the same project, your experts have private offices and your novices use a shared workspace.
(1) Regulations prevent putting expert and novices in a shared workspace.
(2) The expert has poor communication skills or work habits you don’t want replicated!
(3) The expert spends most of her or his time in activities that would disturb the work of any novices within
earshot, such as talking on the phone about other matters.
Forces (1) You need everyone to get work done, both expert and novices.
(2) You want the novices to learn, and the expert has good habits worth learning.
(3) You can afford for the expert to be disturbed a bit more if the novices will learn some good habits.
(1) You don't want to turn the expert into a full-time teacher.
(2) People hesitate to disturb the boss or expert with a phone call or knock on the door.
Do This
Put the expert or leader in the same workspace as the more novice workers, so that the novices can learn by
watching and listening, while the expert does his or her usual work.
(1) Novices will pick up expertise and (hopefully good) habits from the expert.
(2) Your expert will be disturbed more often, so you or he or she will have to set up ways or conventions to
create personal quiet time.
(3) You and the expert have to watch that the novices do not simply delegate their problems to the expert.
(4) You will have more people in the room.
(1) Too many questions will lower the expert’s productivity too much.
(2) Too many people in the same room will create too many conversations, making it hard to concentrate.
Training:Day Care says "Your experts are spending all their time mentoring novices, so ... Put one expert in
charge of all the novices; let the others develop the system.") [CoSOOP]. This covers the dangers of having
the expert try to teach while designing. In Expert In Earshot, the expert is not responsible for teaching the
novices. The situation is only set up so that the novices can see and hear how the expert works, in
accordance with the principles. [15]
Pair Programming is a non-conflicting possible partner pattern to Expert In Earshot. It can be used to bring
an expert within earshot of one person (the other person in the pair), or of many people - all the rest of the
people in the workspace.
(1) When Thomas J. Watson, Jr., ex-CEO of IBM, went from being an aviator and playboy to a serious
businessman, his father, then CEO of IBM, assigned him to sit at the corner of the senior-VP's desk for six
months. For those six months, he was to do nothing but watch and listen to how this successful executive
ordered his days and handled people. This is an unusual but very clear example of Expert In Earshot.
(2) A team leader given four junior designers to design a graphics workstation, was also given a private
office. After a few weeks, he felt uncomfortable with the distance to his team, and moved his desk to the
floor with the other designers. Although the distractions were great and his main focus was not teaching the
other designers, he was able to discuss with them on a timely and casual basis. They became more capable,
eventually reducing the time he had to spend with them and giving them skills for their next project.
(3) The lead programmer worked in a room with six novice programmers. He had two bad habits: he scoffed
at the idea of doing design in an orderly way, and instead of talking to the other programmers about how to
make a good design or program, he would change their code in the middle of the night. They never knew in
the morning if their program was the same as when they left it. After several months, the novices both
produced bad designs and refused to design carefully. His heroic attitude had become their ideal.
When he left the project, another consultant took his place, also sharing the room. He deliberately
discussed designs from his desk, so the others could overhear. After a few months, three of the novices
started talking and drawing designs, and soon became skilled in designing as well as programming.
... Previous research reported that collaborative process modeling resembles pair programming [9]. The benefits of pair programming compared to individual programming are, among others: (1) improved quality of the produced code, supported by significantly lower end defect content, (2) faster task completion, and (3) increased participant satisfaction [5]. Given the benefits of pair programming, and the similarities between coding and modeling, it seems reasonable to expect similar benefits from pair modeling. ...
... Pair programming is a well-established technique with a driver and a controller role. Several authors have investigated pair programming as reported in [5,15,18,22]. In [5], a set of benefits of pair programming is reported. ...
... Several authors have investigated pair programming as reported in [5,15,18,22]. In [5], a set of benefits of pair programming is reported. The first benefit is the ability for the programmer in the controller role to spot typos made by the programmer in the driver role, which otherwise would not be observed until a later stage in the programming task. ...
Pair programming is a technique where two programmers work together. This technique offers benefits such as improved quality of the code, faster task completion, and increased participant satisfaction. Existing research in Business Process Management has not studied the advantages of pair process modeling in comparison to individual modeling. In this paper, we focus on the effect of conducting modeling tasks in pairs on process model quality and participants’ satisfaction. In an experiment, we let novice modelers perform modeling tasks individually and in pairs. Contrary to pair programming findings, we could not statistically support that pair modeling improves the process model’s quality. Similar to pair programming, the experiment did reveal that the participants are highly satisfied when performing modeling tasks in pairs. Considering this result, instructors or managers may want to use the pair setup for training purposes.
... There are multiple ways to construct teams in pair programming, such as expert-expert, expert-novice, and novicenovice [24]. Novice-novice pairing brings specific benefits and challenges. ...
... Novice-novice pairing brings specific benefits and challenges. For example, even though novice-novice pairings can be more effective than two novices working independently, it is generally discouraged as it is harder for novices to develop effective habits without an expert role model [24]. Remote pair programming (or virtual pair programming), where the two partners interact virtually using collaborative tools and screen sharing, is effective. ...
... Some of the case studies on the agile methodologies from a knowledge perspective also directed towards embeddedness of KM in agile practices: Study of two software development organizations highlights the significance of tacit knowledge in agile methodologies and knowledge management aspects of agile development [18]. Pair programming also seems to benefit teamwork, knowledge transfers, and learning (Vanhanen and Lassenius, 2005; [2,10]). ...
Full-text available
Despite the profusion of research about knowledge management within larger organizations, fewer studies tried to analyze knowledge management in small and medium enterprises. The study contributes to research by providing a more nuanced classification of knowledge management approaches and guides managers about the types of knowledge management approaches that should be adopted based on the size, geographical dispersion, and task nature of the organization. A purposive sample of 34 companies was selected for this study along with a survey that focused on the objective of investigating awareness and implementing strategies of knowledge management. The various phases and processes of knowledge management were accounted for. Organizations were bifurcated on the criteria like the core area of the company, the size of the company, the type of company, etc. Knowledge management implementation was judged through each dimension. Different statistical tests were carried out to test a set hypothesis. Having established that wide variation in overall adoption of knowledge management practices exists across the software engineering organizations, the different characteristics associated with knowledge management adoption were tested: organization size in terms of employee strength, the domain of the software engineering, team distribution, and type of organization. To a surprise, most of the organizational characteristics are not found in the significantly associated with knowledge management adoption except knowledge management adoption level in full and partial agile organizations and the relationship between the organization KM level and the number of software developers in organization for only product development companies is found significant. Opposite to the claims of many researchers, this study does not find any significant difference between knowledge management adoptions between distributed and co-located agile teams.
... One student, the driver, writes the program, while the other, the navigator, provides direction, encouragement, and debugs in real-time. Student benefits from this collaborative learning approach include 1) the opportunity for "continuous review" where defects are corrected as they arise, 2) greater satisfaction in the course and learning from peers, 3) team building, communication, and improvement of other soft skills, and 4) greater industry and productivity [8,17]. Researchers have discovered a 95% increase in confidence in the final product and found that "pair programming is 40-50% faster than programming alone" [12]. ...
Full-text available
Pair programming has been highlighted as an active learning technique with several benefits to students, including increasing participation and improving outcomes, particularly for female computer science students. However, most of the literature highlights the effects of pair programming in introductory courses, where students have varied levels of prior programming experience and thus may experience related group issues. This work analyzes the effect of pair programming in an upper-level computer science course, where students have a more consistent background education, particularly in languages learned and best practices in coding. Secondly, the effect of remote pair programming on student outcomes is still an open question and one of increasing importance with the advent of Covid-19. This work utilized split sections with a control and treatment group in a large, public university. In addition to comparing pair programming to individual programming, results were analyzed by modality (remote vs. in person) and by gender, focusing on how pair programming benefits female computer science students in confidence, persistence in the major, and outcomes. We found that pair programming groups scored higher on assignments and exams, that remote pair programming groups performed as well as in person groups, and that female students increased their confidence in asking questions in class and scored 12\% higher in the course when utilizing pair programming.
... Computer programming is a creative but complex task and findings have shown that it can be facilitated with collaboration [1]. Many studies have been conducted on Pair Programming (PP) or team work [2], [3] and Distributed Pair Programming (DPP) [4], [5] in order to study how Computer Science/Software Engineering students benefit from working in pairs or teams, co-located in the case of PP or remotely in the case of DPP. All of the studies highlighted the feasibility of collaboration when the underlying infrastructure allows for all necessary interactions [6]. ...
... The pair programming is the practice to pair two programmers work together on the same code and in the same development environment. The rationale behind this technique is that it may promote communication, and cooperation among peers leading to increase quality of the software, and productivity [4]. ...
... This way, Pair Programming is one of the methods that the Coding Dojo uses to promote learning. One of the benefits of Pair Programming is that it allows constant knowledge sharing with the programmer's team (Cockburn and Williams, 2000). In this approach, two persons use a single workstation and act together to pursue a goal. ...
Full-text available
The Computational Thinking (CT) teaching approach allows students to practice problem-solving in a way that they can use the Computer Science mindset. In this sense, Collaborative Learning has a lot to contribute to educational activities involving the CT. This article presents the design and evaluation of a Collaborative Learning framework for the development of CT skills in students. To design the proposed strategy, several fundamental features of the Collaborative Learning concept of the literature have been studied and sketched. The strategy was applied to middle school students through a digital games programming workshop. Data were collected by three means: (1) collecting artifacts produced during activities; (2) recording of game programming sessions; and (3) applying a structured interview to students. The data analysis showed evidence that the strategy was able to mobilize Computational Thinking skills in addition to mobilizing collaborative skills in learners.
... Codeon is related to pair programming [250], a method that allows developers to work together in real-time more effectively. In particular, it is most related to distributed pair programming, which is a derived version of pair programming, allows remote participants to contribute to the same codebase simultaneously [251,252]. ...
Creating an artifact - such as writing a book, developing software, or performing a piece of music - is often limited to those with domain-specific experience or training. As a consequence, effectively involving non-expert end users in such creative processes is challenging. This work explores how computational systems can facilitate collaboration, communication, and participation in the context of involving users in the process of creating artifacts while mitigating the challenges inherent to such processes. In particular, the interactive systems presented in this work support live collaborative creation, in which artifact users collaboratively participate in the artifact creation process with creators in real time. In the systems that I have created, I explored liveness, the extent to which the process of creating artifacts and the state of the artifacts are immediately and continuously perceptible, for applications such as programming, writing, music performance, and UI design. Liveness helps preserve natural expressivity, supports real-time communication, and facilitates participation in the creative process. Live collaboration is beneficial for users and creators alike: making the process of creation visible encourages users to engage in the process and better understand the final artifact. Additionally, creators can receive immediate feedback in a continuous, closed loop with users. Through these interactive systems, non-expert participants help create such artifacts as GUI prototypes, software, and musical performances. This dissertation explores three topics: (1) the challenges inherent to collaborative creation in live settings, and computational tools that address them; (2) methods for reducing the barriers of entry to live collaboration; and (3) approaches to preserving liveness in the creative process, affording creators more expressivity in making artifacts and affording users access to information traditionally only available in real-time processes. In this work, I showed that enabling collaborative, expressive, and live interactions in computational systems allow the broader population to take part in various creative practices.
Background: This study focuses on how group communication affects group productivity. The specific scope of the study is pair programming. The study aims to discover whether intra-pair communication in pair programming has a significant impact on the pair programming process and output. Literature review: Many of the pair programming communication studies are descriptive and qualitative studies whose foci lay more on communication contents and alternative message deliveries. As a result, more research that focuses on analyzing the effectiveness of a person's communication skill level while performing a demanding task is needed. Research question: Does the communication competency level significantly impact pair programming output? Methodology: A pool of novice university programming students was deployed for the experiment. The Conversational Skills Rating Scale (CSRS) was used to categorize them into three cohorts—"high-high,” “high-low,” and “low-low.” The confounding variables were controlled. Results: No significant difference was found among the three cohorts in terms of their pair programming code output. Additionally, the post-experiment questionnaire responses revealed no significant difference in compatibility and confidence levels, but did show a significant difference in communication level. Conclusion: With all things being equal, a programmer's high communication skill level doesn't play a significant role in the programming output in a pair programming setting.
Full-text available
This paper introduces a new approach — Distributed Cognition — to viewing collaborative activities and analyzes a pair of programmers performing a perfective software maintenance task in accordance with this approach. Distributed Cognition takes as its unit of analysis a complex cognitive system: collections of individual and artifacts that participate in the performance of a task. The external structures exchanged by the agents of complex cognitive systems comprise its "mental" state and unlike individual cognition, where mental states are inaccessible, these states are observable and available for direct analysis. Through an analysis of these structures, their trajectories through the system, and their transformations, it will be demonstrated that complex cognitive systems engaged in software development tasks possess cognitive properties distinct from those of individual programmers. These properties are important for the system's successful completion of the task, yet they are ignored in studies of individual programmers. Studies of system level cognitive properties, when combined with existing research on the cognitive properties of individual programmers, should lead to a more comprehensive understanding of the process of software development. Before this integration can be made, however, these system level properties must be uncovered. The following research is a step in this direction.