Stack OverflowDoes pair programming work?
[+59] [28] Mnementh
[2008-11-14 22:20:13]
[ agile experience extreme-programming pair-programming ]

At our company, we the developers tried some methodologies to be more productive. One thing we could not try was Pair Programming. The reason is, that we are a small company and have only few programmers (and more non-programmers). So it would be impossible to explain to our boss, that two programmers sit at the same computer and solve together the same task. Usually we all even work on different projects.

So I'm interested in your experiences: Does Pair programming work? I mean, does it make a team more productive? Clearly the two are more effective, than only one programmer working on the task. But does the pair can complete the project faster than the two programmers working both on the project, but with different tasks and different computers?

(8) I prefer Apple programming myself... :-) - Sherm Pendley
(2) Do informal code reviews then. - Quibblesome
(2) First, ask your programming partner if online forums work for answering programming questions. :-) - Ken
Closed ad offtopic? "Questions on Stack Overflow are expected to generally relate to programming or software development in some way, within the scope defined in the faq." I look in the FAQ: "practical, answerable problems that are unique to the programming profession". Seems to match. Close it if you want, I got my answer. - Mnementh
[+44] [2008-11-14 22:31:50] vfilby

I tend to use pair programming as a tool to use rather than a constant philosophy. Some example situations:

  • New developer on the team
  • Really complex or difficult code where two eyes/minds will help
  • Code that only one dev is familiar with.

(3) Fully agreed. Our team has found that for most tasks our productivity goes down when pair programming, but for some tasks (i.e. those listed) it is useful and a key tool in the toolbox. I'd also add that even seasoned developers can benefit from the exchange of knowledge, e.g. new tricks and tips. - Greg Case
(1) My experience differs - for almost every task, pair programmings seems to increase productivity. To notice that, though, you need to include later bug fixing and extensions to the code in your measurement. Less bugs and better designs are some of the biggest benefits of PP. - Ilja Preuß
Pairing is definitely great when bringing new people into unfamiliar code. Other times it can be a bit of a waste... - TM.
(3) Of the few times I pair programmed with other developers, I was the more junior of the two, and it was with a developer who was more familiar with the code. It certainly did wonders for me, as an observant junior developer, seeing the tricks that other developers have spent years figuring out. - Hooray Im Helping
Not sure how I ended up here years later, but I agree with this. Pair programming works in situations that are suited for it, and fails to work in others. The trick is knowing which is which, and also avoiding the policy-wonks who like to decree "all code everywhere must now be pair-programmed without exception, because I saw something online that said that pair-programming is good". - aroth
[+43] [2008-11-14 22:44:08] akuhn [ACCEPTED]

You are lucky, Pair Programming is one of the few (if not the only) agile technique that has been validated in an empirical experiment.

Read for yourself: Arisholm, "Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise", TSE 2007. [1]

Abstract A total of 295 junior, intermediate and senior professional Java consultants (99 individuals and 98 pairs) from 29 international consultancy companies in Norway, Sweden and the UK were hired for one day to participate in a controlled experiment on pair programming. The subjects used professional Java tools to perform several change tasks on two alternative Java systems with different degrees of complexity. The results of this experiment do not support the hypotheses that pair programming in general reduces the time required to solve the tasks correctly or increases the proportion of correct solutions. On the other hand, there is a significant 84 percent increase in effort to perform the tasks correctly. However, on the more complex system, the pair programmers had a 48 percent increase in the proportion of correct solutions, but no significant differences in the time taken to solve the tasks correctly. For the simpler system, there was a 20 percent decrease in time taken but no significant differences in correctness. However, the moderating effect of system complexity depends on the expertise of the subjects. The observed benefits of pair programming in terms of correctness on the complex system apply mainly to juniors, whereas the reductions in duration to perform the tasks correctly on the simple system apply mainly to intermediates and seniors.


(3) So in other words, the empirical data shows that its not worth the pain and suffering =) - FlySwat
(7) I don't know Jonathan - a 48% increase in correctness of complex systems sounds significant to me. - Erik Forbes
(4) Depends from what base - if only 1% of solo programmers solved the task correctly, then switching to pair programming to reduce your failure rate from 99% to 98.52% doesn't sound to me like a winning strategy ;-) - Steve Jessop
I know a lot of people who actually find PP to be fun. There are some skills to be learned, though. Don't expect your first PP session to go smoothly. You wouldn't expect that from your first skiing session, either, would you? - Ilja Preuß
(26) This test kinda misses the point a bit, doesn't it? I figured the most important aspect of pair programming is knowledge transfer and quality control. If everyone was new to the system then pair programming wouldn't help so much. - Quibblesome
(12) I think this research is useful but it is asking the wrong question. It shows that developers are more likely to get a specific task on an unfamiliar and complex system correct if they work in a pair. I don't think most developers actually spend much time on this sort of task. I think everyone accepts that sometimes two heads are better than one, the important question is really: how much time should be spent pair programming? - Keith
Putting pepople on a task in a new problem domain for just a day will of course imply a significant introduction overhead, so "do not support the hypotheses that pair programming in general reduces the time required" is a very weakly based conclution. - hlovdal
[+18] [2008-11-14 22:22:21] HanClinto

That's like asking if marriage is a good idea: Depends on the people.

But yeah, I understand that it's hard to convince a boss that pair programming can work. A couple of years ago, I worked on an embedded project where we only had one license to the compiler, and it was locked to a single computer that another developer and I shared. We worked very closely together on the code, and at times it was hard to distinguish between normal shared development and pair programming. It was fantastic, and we got a lot done -- we really played off of each others strengths and weaknesses, and blazed through some very difficult problems. But I know that wouldn't have worked for all of my co-workers, or all of the projects we were on -- pair programming just happened to be a particularly good wrench for that particular problem.

Especially because both he and I are somewhat ADD and easily distracted by other things (stack overflow anyone?), it helped keep us both on task and moving at a good clip -- it was great.

Since then, I haven't done any pair programming, but should the situation present itself, I would like to try it again. I think it's a good idea that has potential to be very powerful (when correctly applied).

For more success and failure stories, don't forget to browse the other related questions [1].


mmmmm then PP must be a pretty promiscuous affair since we are always changing partners... But yes, the greatest benefit I felt PP gave was it kept both of us focused at the task/topic at hand instead of letting our minds wonder and think of other stuff, wikipedia, youtube.... - icelava
[+12] [2009-05-12 18:19:18] Cam Wolff

The benefits experienced by the agile teams that I am responsible for are as follows:

  • Improved quality: A pair of active programmers working on the same story card will complete the card with less defects
  • Improved productivity: a pair is less likely to be slowed down if not outright blocked when solving a problem. Furthermore, it is harder to take an email or web vacation when you are working with a partner ... you don't want to let the partner down. You will solve the problem with a cleaner design and less lines of code when working as a pair
  • Eliminate silos of knowledge: With rotating pairs, you will learn application and domain business knowledge across the team. The team is less likely to be blocked because Sue went on vacation and no one else knows her code.
  • Skills Transfer: Rotating pairs teach new skills (engineering and domain) to each other as they work together. The level of the team will rise for everyone and the knowledge propagates through the team.
  • Team self selects: The team learns one anther's skills and will quickly weed out someone that is not performing.

From actual experience we have seen defects drop significantly. New team members can be added without slowing down the team (try that with a non-paired team). For a trial, one team estimated the work for a set of story cards as if six single developers would complete the code individually. The six developer were then told to pair. They completed the work on time with high quality. If you don't pair, you are spending to much time to deliver to little quality, you have no way to scale and you have too many silos of expertise.

In a second example, we estimated to complete the work in the time requested we would need to take a team from 4 pairs to 7 pairs. We gave ourselves 1 month to on board the new pairs. We paired a new developer with an experienced developer and rotated the pairs across story cards. The team hit all deliverables with quality in the time planned. Without pairing one could not have added 6 developers to a team of 8 developers and hit the mark!

Bottom line, pairing works. You will take about the same time, delivery with higher quality, improve the teams performance, skills and knowledge and weed out the dead wood. Your savings will come with sustainable pace and significantly fewer defects in the way to slow the team down.

Fascinating stuff, thanks for sharing Cam. - Yar
(2) Reading through this brings to mind one significant point that is overlooked: management. Getting something like what you described to work requires a level of management skill that is hard to come by in our industry. I find most managers to be either 1) highly-skilled developers who got promoted and thereby SERIOUSLY lack management skill or 2) highly-skilled managers who SERIOUSLY lack development knowledge. Getting an agile team to perform as you described would be impossible for 99% of Managers I've ever known. - gmale
[+11] [2008-11-15 15:45:32] RoadWarrior

IMX, pair programming with people who like the process and respect their pair can be effective in some situations. For example, learning a new technology or component, or doing low-level design with specific goals in mind.

But forced pair programming is a very bad idea in any situation. The lack of privacy and quiet thinking time are serious productivity killers. The best software development comes after you absorb yourself in a problem and do a lot of deep thinking - this doesn't lend itself to pair programming.

On a personal note, if you pair me with somebody I don't respect.....well.....what's it called when you split them down the chest, pull their ribcage apart, arrange their non-essential organs outside them, then wait for them to die?

EDIT: Another thought is that other creative professions don't usually pair, e.g. cooks, painters, authors, etc. And I love this Dilbert cartoon [1].


The typical stack overflow reader might not be able to spot rhetorical questions. Anyway, is it "vivisection"? - Andrew Shepherd
I didn't think it was rhetorical at all... I would not be surprised in the slightest if one programmer really does want to split another programmer down the cest, crack the rib cage and remove certain organs. - Neil N
In Norse legends, it's called "carving the blood eagle" on someone. Not sure I want to encourage its revival in programming contexts, though! - thesunneversets
[+8] [2008-11-14 22:30:55] erickson

It's rare to find one stellar programmer that's better than two decent programmers, working together. (They do exist, though.) So, pair programming can work a bit of alchemy in that respect. But the key is putting peers together; putting a bad programmer with a good one doesn't improve the bad programmer, and it makes the good one want to quit.

Note that "bad programmer" is not the same as "new programmer"—and that "pair programming" is not the same as "mentoring". The mechanics of mentor-pupil are very different than peers doing pair programming. I think it helps to recognize the difference in roles explicitly. It emphasizes that the mentor needs to provide plenty of explanation about the "why," not just "how" (as well as a bit of extra patience), while the student is expected to actually learn and internalize the lessons so that eventually he can do it on his own.

In response to OP's comment:

Depends on the programmers, but yes: A rockstar can do the work of 3 or 4—sometimes more—programmers. For work that is unfamiliar, innovative, or error-prone, pair programming can yield results similar to those that a superstar might produce, so 1 + 1 >= 3. But on routine crud that wouldn't challenge a rockstar, pair programming might not be cost effective.

"Rockstars" can really be a bargain, since they do the work of two or more but don't generally cost twice as much as a solid Joe Sixpack. So, if you find one, count yourself lucky—but don't base your business plan on that kind of luck.

(3) It's clear to me, that a pair will work better, than a single programmer. But does it work more effective than the two programmers on their own? - Mnementh
[+4] [2009-05-11 01:24:07] zvolkov

For me, pair programming definitely works, but only when paired with a dev of approximately my level. There's no doubt I work faster and accomplish more:

  • I stay more motivated, excited and energetic due to the fun of sharing my day with another person
  • If I loose the train of thought the pair catches up and vice versa
  • I do not procrastinate and don't waste time browsing the web
  • The pair always reminds me to follow coding standards and not lean too much to quick and dirty on one side and overengineered on the other
  • The pair catches errors as I type, which saves some time too
  • When it gets to decision making it really helps to have somebody to talk to right away, no need to schedule a meeting, no time spent catching other person up.
  • No need for code reviews, as the code is reviewed as we write it
  • I do not overcomplicate the solution and don't overresearch unlike when working alone
  • When I get tired, we switch seats and go on with same super speed
  • My pair works 7am - 3pm and I work 10am - 6pm. This way we still get enough privacy and have opportunity to do research, deep thinking, analysis, troubleshooting, emails, documentation, status reports etc.
  • Since we both know the code intimately we are the ultimate backup for each other in case one of us gets sick or needs to go on vacation.
  • We go to MSDN less since between two of us there's a higher chance that one of us knows the answer from the top of his head.
  • There are lots of productivity-enhancing tricks, shortcuts and other best practices we learn from each other

I wouldn't want to pair with a junior dev though.

[+4] [2009-05-11 02:08:12] TM.

Your devs have to be interested and receptive to the idea.

I've had some great experiences pairing, and been very productive. It's a great way to get a developer up to speed on a project and to spread the knowledge so that it isn't all confined to one or two people.

However: If a developer does not want to pair, it will not be effective. I've seen developers who didn't think it was a good idea come around to the concept and change their minds, but it requires an open mind.

Every time I've witnessed a person pair who does not want to, it always turns out poorly. They don't pay attention when the other person is typing (thus removing them point of them even being there). When they are typing, they don't talk or explain, and they get upset when the other person questions them or makes a suggestion.

Certain personalities do not work with pairing. If your organization has a lot of these people, don't make them pair. It makes both people upset and the person who doesn't like the concept will blame any failings on the pairing process (regardless of the real reason).

Side note: certain tasks also do not lead themselves well to pairing. Basically anything that is tedious or "very easy" to both partners will generally be wasted time.

At my company we try to be flexible and pair when it makes sense.

I believe that on a large team, it's a mistake to pair for everything, but it is also a mistake to not use pairing when it makes sense.

[+4] [2009-05-20 11:52:14] Keith

I think that it's generally accepted that pair programming is sometimes are really effective tool - two devs hacking away at the same thorny problem, or one dev showing another how it's done are both really valuable.

The important question is: how much?

XP says all the time, but I spent a lot of time dealing with really mundane tasks - everyone does. New tools like ASP MVC help reduce this time, and good design reduces it too, but everyone has some and that time is wasted if two devs are doing.

Even more than that an awful lot of the time the problem just isn't that difficult - a bit of analysis and in depth thinking is needed, but it's not really a two-person job.

I think a good, practical and real-world way to answer this question is to look at what real world successful teams do. So:

How much time to companies have their devs spend pair programming?

Google - No more than 5%, according to Steve Yegge [1]

Microsoft - About 6%, according to a survey of internal MS devs [2]

37signals (inventors of Ruby on Rails) - None, but use small close teams instead according to their book: Getting Real [3]

General usage - around 31% of agile shops use pair programming at all according to VersionOne's 2008 survey [4], but it's not known how much they use it (all the time, or only some?)

My conclusion? It fits into my more general guidelines [5], but while pair programming is a really valuable tool it isn't appropriate all of the time, or even most of it. Use it to share information, attack a tough problem, learn a new technology or mentor/train. Don't use it the rest of the time.


(1) If a team is new, has new members or is working on a new application, developer pairing for all code going to production is a good rule of thumb. If a team is mature (knows the app, all members are experienced and has zero or near zero defects) then the team can decide to not pair on the simplest task. - Cam Wolff
[+3] [2008-11-14 22:35:48] Vyas Bharghava

There're lots of team dynamics involved. Pair Programming per se has Weak-Weak, Weak-Strong, Strong-Strong pairing. I found the second only works if the Weak programmer is willing to learn and watches closely. Also equally important the strong programmer is open to suggestions, is willing to coaching the weak programmer (rather than have his ego bruised).

Strong-Strong pairing usually works if both have been together and share the same frequency. As such Pair Programming requires the pair to have respect for each other. Otherwise, it's not guaranteed to work.

[+3] [2008-11-14 22:33:09] EBGreen

How about pitching a limited pair experiment to the boss. For instance you pair one day a wek for only an hour or two. For this time I would stress working on code that is a design challenge or on library code. The design challenges will benefit from the synergy of two people with different design backgrounds looking at the same problem. The library code would benefit because more people will understand it at the dev level. THen after you have done this for a few months do an honest objective write up for your boss highlighting where it was a good experience and where it wasn't. Maybe you will find out that it isn't the right thing for your team. Or, maybe you will identify a certain problem domain where it really helps your team. Just tell your boss that you won't go into the experiment with the assumption that it will solve all your problems as long as he doesn't go in with the assumption that it is a waste of time.

[+2] [2008-11-14 22:33:22] FlySwat

Personally, I think PAIR programming is a scheme invented by project managers and IT to cut down workstation cost =)

As you can tell, I'm not a fan :)

If I need someone else to look at my code, we just do a remote desktop environment. If any job asked me to share a workstation and alternate typing, I'd quit on the spot. I'm a strong believer in a good work environments, and I don't know how anyone could tolerate that.

It seems that you have some misconceptions about PP - it doesn't disallow you to have your own workstation. And using a remote desktop environment is in fact a valid implementation of PP, although personally I prefer to actually sit next to each other. - Ilja Preuß
We pair program sometimes and we still have our own nice desks and nice workstations.. - TM.
[+2] [2008-11-14 22:53:52] Stephan Eggermont

My personal experience with pair programming in a small team is very positive. But we were trusted to decide for ourselves what works best.

In my current job I see the problems of not pair programming a lot: not enough people able to work on code written by others, too many unchallenged assumptions in the code, not enough learning of modern ways of working.

[+2] [2009-05-11 01:53:36] Francis

If you have several experienced programmers and some new juniors, you should really try it (if you have resource to afford it).

Pair programming is the best training method I've ever seen.

(1) It definitely gets new developers familiar to your existing code in very short order. When I started, I had to slug it out on my own reading old code. Nowadays I pair with new people for 1-2 iterations and they get up to speed in no time. - TM.
[+2] [2008-11-15 18:00:18] StingyJack

Pair programming with someone who has gas is no picnic.

(1) That comment belongs on a t-shirt. - Bob Black
[+2] [2008-11-15 00:02:24] Arkadiy

Personally, I found pair programming to be very challenging, and was unable to practice it successfully. I came to conclusion that at least for me, "pair programming" with more junior person does not work - I end up doing all the work myself, whether I am driving or not. In general, fine balance between paying full attention and not taking over is a skill that needs working on. I did not have enough exposure to pair programming to acquire it.

Was the junior person tuning out and letting you do all the driving? Maybe you needed to pass them the keyboard more often -- it's hard to stay disengaged when you're the one who's expected to type something. - Joe White
One of the key goals of pairing with a junior is to show them the right way to do it. Taking over and doing it yourself wasted the valuable training oppurtunity. - Neil N
[+2] [2009-05-14 13:42:57] Kai Wang

In my personal experience, pair programming always becomes one talking/typing the other listening/sleeping in the end. :(

Then your team is not doing pair programming. Both sides of the pair are to be active. If you switch the keyboard frequently it will keep both invested. One looks at syntax, the other design and semantic issues, switching back and forth frequently as you switch the keyboard. If you don't switch the keyboard and you don't switch pair then your developer pairing will lose its effectiveness - Cam Wolff
[+2] [2010-09-20 08:48:51] Doro

Of course it works, if you do it right. Have a look at the agile42 blogpost regarding Pair Programming [1].


[+2] [2010-09-22 20:44:49] kevj

Depends what you mean by "Work" Why do you want to do Pairing?

For me the emphasis is always on quality and the disciplines to continually increase the quality I have found pairing to be one of the techniques essential for me to make sure I focus on DONE DONE. Because I do this with a colleague I feel energised and we get more done, we deliver value often and its potentially shippable, we meet our sprint commitments, we learn continually by communicating all the time, we gain confidence in our decisions all the time. Try code reviews and inspect what you did, notice that it will generate rework, the longer you take before you review the greater the risk you will have more rework to do and therefore you will not meet your sprint commitments..

I love pairing, take a look at pivotallabs tech talks and see how they work.

[+1] [2009-11-24 18:03:45] JB King

Where I work for some tasks we generally pair to get the new functionality done. The pair prevents what I'd call the code spew that can happen when one developer just creates a ton of code but it isn't easily read and understood by others.

While I don't think a pair can complete a project faster, there are some trade-offs worth noting. Pair programming prevents a sense of individual code ownership so that the code base is a team result rather than just a solo effort. Just because something is done, doesn't mean it is done well. Some people can understand that and some can't. There may be some time savings in those cases where one developer's work would have to get refactored so the rest of the team can understand the code easier, but I'm not sure how often that would occur.

Pair programmings works really well where I am. There was also a time where a couple of consultants were brought in to pair for a couple of weeks that really upped the game here. The consultants were great at sharing techniques and changing the culture a bit so that everyone worked better and there seemed to be more confidence and pride in the team which helped productivity, IMO.

[+1] [2009-12-10 09:00:08] Jag Reehal

I wrote a blog post to to share my experiences and opinions on pair programming - Pair Programming Is Not a Silver Bullet [1].


[+1] [2009-05-11 00:08:50] community_owned

Convincing your boss is the first hurdle and yes it’s a doosie, but it’s just the price of admission. The real fun starts when you sit next to your partner and try to prove your boss wrong. Take a look at 5 ways to fail at pair programming [1]


[+1] [2008-11-14 22:38:49] hectorsq

At our very small company we use what I call pair designing only when the problem is hard enough.

A few months ago I sat with one of my colleagues for about 3 or 4 days in which we were designing an specially difficult algorithm. After the main design was defined my colleague continued programming it alone.

I have found it useful when the problem is harder than normal or when one of the programmers is new to the subject matter.

[+1] [2008-11-14 23:32:30] le dorfier

No matter what your level of expertise, there is (IMHO) lots of reason to think that explaining your code to someone else is the best way to self-check for accuracy and completeness. I personally think a developer is substantially more productive if there is a semi-conscious user-surrogate sitting next to them. Someone who actually can give technical feedback and demonstrate understanding just amplifies the effect.

OTOH, I've seen lots of code produced by developers who can't explain it conceptually at all. They sometimes will explain "I messed with it until it worked." Then you're in trouble.

[+1] [2008-11-14 23:25:42] Kendall Helmstetter Gelner

At a small company you cannot afford to hire people who would be more productive in pairs than individually.

That is to say, pair programming helps if one or both of the people lack either technical or domain expertise. But again, in a small company (such as the one you are working for) do you really feel that the people working there need this kind of boost or can they manage pretty well by themselves?

In my experience, almost every pair of programmers, no matter how experienced, will be more productive when working in a pair than when working individually. A lot of my gurus, naturally quite experienced developers, prefer to pair program with their peers - for productivity reasons. - Ilja Preuß
[0] [2008-11-14 23:28:18] spacemonkeys

I agree that in my new job ther problem is more likely to a lack of pairing, I was listening to .net rocks and they were talking about pairing 20 minutes a week !!! thats nothing, but it would make you talk about the code (which doesn't happen in my new job) stop assumptions (there are a lot of assumptions) and open up the environment a bit, think anything that encourages interaction between programmers and discussion about how to resolve a problem (even if it a easily solved problem) can only be a good thing .... bit like this site really

[0] [2008-11-14 22:23:54] Chris Lively

My experience has been that this can only make people more productive IF the people involved need someone else to sit there motivating them.

It really depends on your team.

[0] [2009-05-20 12:01:24] Daniel Daranas

Does Pair programming work? I mean, does it make a team more productive? Clearly the two are more effective, than only one programmer working on the task. But does the pair can complete the project faster than the two programmers working both on the project, but with different tasks and different computers?

It depends on the project and the team. Sometimes pair programming will increase productivity; other times it will decrease it or leave it equal. There is no general rule.