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?

+17  A: 

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.

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....

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.

Chris Lively
+8  A: 
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?
+33  A: 

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.
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
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...
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
+3  A: 

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  A: 

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..
+2  A: 

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.

Vyas Bharghava
+1  A: 

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.

+36  A: 

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.

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.

So in other words, the empirical data shows that its not worth the pain and suffering =)
I don't know Jonathan - a 48% increase in correctness of complex systems sounds significant to me.
Erik Forbes
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ß
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.
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?
+2  A: 

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.

Stephan Eggermont
+1  A: 

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?

Kendall Helmstetter Gelner
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ß

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

+1  A: 

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.

le dorfier
+2  A: 

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
+9  A: 

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.

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!
+2  A: 

Pair programming with someone who has gas is no picnic.

That comment belongs on a t-shirt.
+1  A: 

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

+4  A: 

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.

+2  A: 

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.

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.
+3  A: 

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.

+9  A: 

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.

Cam Wolff
Fascinating stuff, thanks for sharing Cam.
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.
+2  A: 

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

Kai Wang
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
+4  A: 

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

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

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

General usage - around 31% of agile shops use pair programming at all according to VersionOne's 2008 survey, 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, 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.

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

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.

Daniel Daranas
+1  A: 

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.

JB King
+1  A: 

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

Jag Reehal
+2  A: 

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

+2  A: 

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.