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.

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

Pair programming with someone who has gas is no picnic.

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.

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

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

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.

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.

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

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]

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.

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.

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?

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

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.

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.