Fog Creek Software
Discussion Board

Pair Programming successes and failures

It seems that there are many people enamored with pair programming, but I think far fewer people give pair programming a try compared to other parts of XP such as unit tests.

I have not worked in a shop doing pair programming, so I'm writing strictly based on intuition. I can see pair programming being very valuable in getting past certain types of bugs, eliminating towers of knowledge, and helping more junior programmers become better by witnessing firsthand the thought process that a more senior developer uses.

But, I'm not convinced that the overall benefit is worth the cost of having two programmers working side by side all day, every day. Joel has written about "being in the zone", a state of solid concentration that allows a programmer to tackle all sorts of interesting tasks (which is part of the reason that Joel advocates single offices). I've definitely experienced this myself, and I think this is something that you lose by pair programming. It seems difficult to believe that two people can be in the same zone and have the same kind of focus.

I do think that periodic pair programming can be very useful for working through difficult bugs.

What kinds of experiences have you all had?

Kevin Dangoor
Wednesday, December 26, 2001

When I need help with a bug, I just ask one of the team to drop by "when they have a second" and as soon as they show up I usually figure out the bug just in the process of explaining the problem to them.

I'm not sure how I feel about "in the zone" programming.  I don't find writing code particularly difficult, so I don't have problem with putting it down and picking it back up again multiple times a day.  Most of the detailed design work we do with at least two developers, sometimes more, and the design work is usually a lot more difficult than coding.  As for debugging code, often I just need to get interrupted a bit and the solution becomes obvious.

Matthew Cromer
Wednesday, December 26, 2001

This is where non-intrusive IM messaging is the way to go. I asked Joel about XP a while ago and he had some great points about how there is no such thing as a "cure all" type of programming method.

IM messaging CAN be  non intrusive way of pair programming. Our offices has adapted many differnt ideals of XP but we have have not done much pair programming because of the "zone" issue. We have instead used ICQ to handle some of the pair programming ideals without the direct interuption of a person looking over your sholder.


Michael Lubrano
Wednesday, December 26, 2001

I have had mixed results so far doing pair programming. Note I don't do it full time but the times where I did, it all depended on who I was paired up with.  The first person I tried to do some pair programming with was a "trial and error" type programmer and was a really good programmer except how he got to the results was no very conventional and didn't match to how I like to write code. We tried to write up some Perl script and eventually had to split up cause we were preventing each other from getting into "the zone". On the other hand, more recently we have done some pair programming periods (less than one hour) and it was quite succesful. Most of the time it was me trying to write some code using another person's library. This type of pair programming is very valuable in my opinion cause you can be certain you are using the library in the right way and also the programmer who wrote the library can learn if the API he designed makes sense.
I think Pair Programming can also be succesful doing the more challenging parts of the code. The rest of the code (the type where you can listen to music and not be derailed) can be done alone and simply have the code reviewed later.

Sylvain Marcotte
Wednesday, December 26, 2001

I noticed the we in "...recently we have done some pair programming periods.." could be a little unclear. It was with a different person than this "trial and error" programmer.

Sylvain Marcotte
Wednesday, December 26, 2001

I've had lots of luck with PairProgramming as I belive its a better work pattern for humans to discuss, create and manage abstraction.  The nature of software devlopment, the actual tasks, are so subtle, detailed, complex and numerous that discussing them committee style is too cumbersome and takes too long.  For example when was the last time you documented a complete OO design (or revierse engineered something into UML) - there is just too many little bits to keep track of and whn you do the volumne of information is too much to keep in your head. 

Two people working on a task can share the zone quite well with a little practice and I'd say even help you stay there.  There have been many times when my momentum has been robbed by some silly little thing that I was doing wrong - when pairing often that silly little thing is caught in mid sentence and corrected keeping velocity high. 

The systems I've worked on tend to be complex and not limited by the quantity of code to be written but rather getting the right code written.  It isn't the typing that is the rate limiting step its the thinking.  Often just getting a team on the same page is the most difficult thing - PP is a great way to do that.

Jim Murphy
Wednesday, December 26, 2001

Our development team at work used to have 8 developers in it. We spent the better part of 6 months solidly using pair programming to refactor a large chunk of the code base and to introduce some new funtionality. About 3 of the team were familiar with a large proportion of the code base and the rest were only familiar with the bits that they had previously worked on and there were 2 new developers that had hardly seen the code.

There were parts of the project that could be worked on seperately, and pairs of developers were delegated to work on those different parts. At various points in the project (usually every month), partners were changed and so were the parts of the projects that were being refactored and developed.

One of the things that was apparent from the outset was that you have to choose the pairs very carefully. Some of the developers were loud and boisterous and didn't mind working with others who pointed out problems and so forth. Others were very quiet and preferred not to work in pairs, and would often not point out obvious problems when they weren't at the keyboard. (Sometimes I would deliberately make a mistake to see if they would point it out). If the latter is the case then pair programming isn't going to add anything to the project. There were also times when junior developers wouldn't point things out to more senior developers.

People need to be the type to point things out and ask questions for pair programming to be effective. When you get two people working together that do point things out, the end results are generally much more solid and innovative than a single programmer.

Of my personal experience, I got particularly frustrated pair programming with people who were slow typers. I just wanted to grab the keyboard to move things along at a faster pace. Another annoying thing is the different code styles that people used. I don't like the Sun Java code style conventions and neither did our lead developer and since the majority of the code base was being refactored we all decided that having one style throughout would be better than 3 or 4 hybrids. The coding style was chosen to be what the lead developer (and myself) liked. It has now become known as the 'one true spacing style' at work and everyone in the team now uses it (whether they like it or not, but generally they see the advantages in it eventually).

During that project I learnt heaps off the lead developer by watching him code and having him point things out while I coded. I have also heard that one of the other developers learnt heaps off me after the fact.

In general the process was good for bringing the new people up to speed with the code base and getting people into good coding habits (good habits tend to get picjed up rather than bad ones), but it was also good for making everyone responsible for the entire code base (@author tags were team based, not individual based). No one person 'owned' a particular piece of the code.

So often I find people don't want to fix problems with code that other people wrote (or even tell them that the code has a problem). I think was the major benefit of the exercise, getting everyone in the team responsible for code througout the entire project. Now when people fix bugs, they don't seem as scared to refactor small portions of the surrounding code at the same time.

BTW, unit tests were also introduced with the refactoring and these were invaluble in picking up small problems that could have escalated into hard to find bugs at later stages. When in doubt, write a unit test; you won't be disappointed... Unit tests also give the developers lots more confidence that their code is doing what it is supposed to do.

So overall, not a bad methodolgy to use if you have the right people. I left that team about 6 months ago, but I believe that they still use pair programming for development of new functionality.


David Teirney
Wednesday, December 26, 2001

My experience with pair programming is 100% negative.
Invariably egos get in the way, particularily if two "guns" are paired. It may work if you pair a bozo with a gun, but its far better to get rid of the bozo and let the gun get on with it.

Pair programming will result in the lowest common denominater being the standard of your team.

Wednesday, December 26, 2001

My first programming was done in "pair programming" with another person, though we didn't know that term then.  It was for a physics dept, and we were modelling hardware.

- We got to know each other's thoughts better, and were able to predict the other person's decisions.

- Far less bugs were made.  Since we were new, we made a lot of boneheaded little errors.  The person sitting back next to the typist would pick them off efficiently.

- Interesting motivational forces were at work.  There's the peer pressure to not slack off.  And an important thing is that your partner becomes your customer.  Most coders are removed from the end user, so they sometimes don't feel the code is important.  Having your partner become a "customer" of sorts changes this.

- It might get in the way of sane work, like actually thinking and designing before coding.  It may encourage cowboy-style coding, at least the dumb variety.

- If people are of deeply varying levels (one is a natural born bozo and the other isn't), this may be a deadly experience.  But I don't have much experience here, unless I happen to be a bozo and unaware of it.

Of course, all these points require a context.  If people are unhappy, they'll just find pair programming another atrocity of daily life.

Richard Jenkins
Wednesday, December 26, 2001

My pair programming experiences have all been good.


1) I pair programmed for an afternoon with my 13 year old nephew,  He learned a lot and I came up with a better design than I otherwise might have had I not made  it simple enough for him to understand.

2) I regularly pair program with a team of talented developers and the experience is always worthwhile.  Sometimes, I learn from them.  Sometimes they learn from me.  Sometimes we both learn. 

It's true that sometimes we have to slow down a bit, but the overall velocity remains high.  Slowing down a bit to share skills or get to know someone elses strength is always a net gain in the long run. 

The rate at which bugs are introduced diminishes a with pair programming (and even more when pair programming is iued with test-first-development, but that's another story)

The studies I have seen on the life cycle cost of software consistently indicate that pair programming costs less than programming alone.  Based on my experience, I believe these studies.  It may be true that these studies were conducted by advocates of pair programming.  I have yet to see any study indicating the opposite.  If anyone knows of one, I would be interested in reading it.

If you have 'guns' whose egos get in the way of pair programming, then they aren't pair programming.  IMHO: they are probably a liability...

Russel Hill
Wednesday, December 26, 2001

Regarding Tony's comment about "guns":

Certainly if people can't let go of ego, it will be hard to pair. I've experienced that. It takes two to let go, which means I was one of the ones who couldn't.  So it can happen.

Regarding lowest common denominator, I have NEVER seen that happen. Even the least capable programmer helps me, if they'll just engage.

I do think you'd possibly get LCD if the two people wouldn't work together. Working together it just can't happen. Can only happen when there's conflict as far as I can see.

Ron Jeffries
Wednesday, December 26, 2001

In my experience (almost 20 years) I have met very few experienced, very talented and productive programmers without an ego.

It comes with the territory.

Typically they can be difficult to manage. Some of them (the best ones) would need a gun pointed at their heads to get them to code in pairs. Some of them (one again the best ones) would probably leave if forced to code in pairs. The next job is always just one phone call away.
The only exception to this is if they are assisting less able developers, after all, they like to be nice people too, sometimes.

Developers typically crave autonomy within their work.
I have found that the better the developer the stronger this craving.
To make them code pair would be torture.

A good team (including the most able) have a culture of peer review, this is where knowledge and ideas get traded.
Not when developers are attempting to be "zoned".

Anyway, I've had my 2 cents worth.

Wednesday, December 26, 2001

Is pair programming working as promised? - Yes it is working.
Is it easy to implement? - No, it is not.

Pair Programming itself is an exotic technique that is a part of XP. Note, it is not XP itself, it is a part of it.

In the XP it have a clear purpose and I found it almost impossible to implement pair programming without other XP practices.

I think out of XP context, pair programming can have very limited use. In our team I was unable to implement it this way. Here is why:

- Developers can't get that it is faster than coding alone. You are moving slower, but later you have less problems that eat your time. But you moving slower NOW, and you promiced to have less problems in the future.

- Developers are usually individualistic and have their own style of working. Almost half of them hate to work in a pair.

- Skill difference have a critical point after which it is almost impossible to work together.

So after year of trying, i came up with decision that XP and Pair Programming in particular should be implemented completely, not practice-by-practice by developer's desire. So now for 5 months we are doing all XP practices.

So now we have Pair Programming working and it is working as was advertised:
- it makes collective code ownership possible
- it helps to have conceptual integrity
- it prevents islands of knowledge
- it makes new team memebers learning much faster

To make Pair Programming work you have to hire right people. In additional to Joel's "Smart" and "Get Things Done" criterias I added "Works in a Team" criteria. Usually if the person is "Smart" and "Get things done" (s)he will have no problems with Pair programming and Collective code ownership.
If person have problems with Pair Programming usually (in our team) this mean he have problems in the "Get things done" area. He have "Get My things Done" menthality. For large enough projects with flat organisational structure this usually leads to problems.

So Pair Programming works well for our teams, but it is not a thing that can be implemented litely.

Roman Eremin
Thursday, December 27, 2001

Read this article:

It is a model how team of programmers should work. You will see a lot of XP-like practices used there.

Roman Eremin
Thursday, December 27, 2001

Like a lot of the rest of XP, Pair Programming is just what's happened since time immemorial for some people.  Frequently XP stands for eXtremely Poor, no methodology should be more important than the product.

Buddy programming, take an experienced engineer and pair them with someone possibly less experienced but with exposure to new bright shiny things.  The more experienced engineer learns something about teaching, listening, mentoring, the less experienced engineer learns how to type faster and hopefully recognise bad habits along with the shape of someone else's mind.

The pair of them also learn how to obfuscate and backup their partner in the face of external pressures.

The above was as true of steam engineers as it is of  software developers.

Developing in pairs isn't magical it still needs careful external management to make sure it goes in the right direction. 

Simon Lucy
Thursday, December 27, 2001

My experiences with pair programming have been good but few. I have only used it in stressfull situations where there was little room for errors (or ego's).
Working in pairs helps to keep eachother focused (in the zone?). It also decreases the amount of interruptions since you are obviously busy with each other, as opposed to a single person who is working alone with a computer who, for an outsider, can easily be disturbed.

In more relaxed circumstances the need for personal freedom in your work beats the aforementioned benefits.

Geert-Jan Thomas
Thursday, December 27, 2001

After reading the comments here, I was hoping some of the Pair Programming advocates could answer a couple of questions:

1) What type of software is being developed?
2) What type of management support do you have?

As a developer of desktop applications for Windows, there are a lot of time-consuming, yet non-thinking tasks that have to be done. For example, handling a simple user-generated event takes time but requires almost no thought. I would think having a second programmer on hand would often be a waste of time. I think pair programming would be very beneficial on other aspects, and to a certain degree, we do that where I work - we often seek the help of another developer to work out problems.

Also, at the company where I work, schedule is often the most important issue, often far more important than quality ("we can always fix it later").  Has anyone who's had success with pair programming had to deal with this issue?

Joe Bauer
Thursday, December 27, 2001

Every time I've done pair programming it has been a great success.  However, I've only done it a few times, all with the same person, a guy I get along well with.  We tend to co-design a lot, so we understand and respect each other quite a bit.  We usually only do pair programming when we expect something to be complex both to design and implement.  That's when pair programming helps the most, because it's like being able to double your short term memory and ability to keep track of all the details at once.  There are many implementations I've done where I wished I'd gone the pairing route, because although I wrote a beautiful piece of code, there were lots of bits I forgot to write or to change while doing a large-scale restructuring.  And that's the kind of thing I've found pairing to help the most with.

Phillip J. Eby
Thursday, December 27, 2001

I have done pair programming with one of my collegues, when were implementing some swing features to a java tool we were developing.

With that experience in mind, I can say the success (or failure) of pair programming has a lot to do with the 'chemistry' of the pair. If you are doing pair programming with your best friend, it sure will be rewarding for both of you. But if the pair guy is a person who is forced on to you by your team lead ...; well you know the situation.

But one thing is sure, it is pretty damn difficult to get into the zone, while doing pair programming. But for most of the coding work that a programmer does, there is no real need to be in the zone.


Eldo Daniel
Thursday, December 27, 2001

Joe Bauer asked some questions.  Here are some answers from my perspective:

1) What type of software is being developed?

We develop indutrial machines. The operator deals with the machine through a fairly traditional GUI.  The GUI presents machine status, product information, and allows the operator to adjust a fairly complex collection of settings.  At the lower levels the machine incorporates both custom hardware and real-time, embedded software.  We have been using pari programming sucessfully in every layer of the software. 

2) What type of management support do you have?

We have very good management support.  Our direct manager is an advocate of pair programming and his boss is also quire supportive.

"We can always fix it later"... 

Yeah, I've been there.  The unofficial motto of a former employer was "Never time to do it right, always time to do it over."  It's a vicious, self-perpetuating cycle.  It is possible to break the cycle.  Pair programming is one of the practices that helps.  It helps because the team spends much less time fixing bugs that shouldn't have been there in the first place. 

It's fairly clear how pairing helps on the complex issues.  However, it also helps on the simple code that seems like it shouldn't need pairing.  That's when developers tend to get sloppy and overlook something simple.  A pair rarely makes those simple mistakes.  There are two distinct advantages here: 1) less time and money are spend fixing bugs, and 2) customers percieve higher quality and responsiveness (i.e. it becomes possible to add more features instead of removing bugs).

Not only that, but practicing pairing on the simple tasks makes it easier to pair the complex tasks.  Pair programming is a skill.  Practice on the simple tasks and it will serve you better on the complex ones. 

I have yet to work at a company where schedule isn't a major issue.  What I can say is that at my current job we aren't generally in a panic to band-aid some problem.  We tend to fix things "the right way" more often that we slap a fix together.    The software is easier to understand and maintain.  The result is that we spend less and less time maintaining band-aids.  Sometimes we still have to band-aid a problem, when we don't really know (or have) the correct solution.  This occurs most often when we have to work around hardware issues.  Often it's a lot easier to work around a hardware issue than to get the hardware guys to fix it. 

Russel Hill
Thursday, December 27, 2001

The only time I did pair programming was with a (then) barely known developer. We sat down one day, with just pencil and paper, and outlined a complete GUI handler, complete with events queue, low level routines, and messaging. It was a funny experience -we joked a lot, sometimes we laughed so hard that other people started complaining so we moved to an empty meeting room. The next day we started typing. Another day of fun and joy. The third day we had a complete (no joke here!) GUI handler for a DOS program we were developing, object oriented and all.

So, my experience with pair programming is really good, I recommend to anyone. You should check complementary personality types, though.

Leonardo Herrera
Thursday, December 27, 2001

Well, I've been Pair Programming, in the XP model, for nearly three years now.  I have PP'ed numerous times over the thirty years that span my career.  I have always thought highly of my skills, but PP always surprises me with how dumb I can be.  My partner will constantly question my decisions and design.  Or, I his.  These are not something that can be discovered after the fact in a peer review.  Or, if it is, you are rarely given the time to make the proper changes.

I have paired with people that resisted it, that embraced it, that knew less than me, that knew more.  There is usually *NOT* a pairing where there are two equals.  But, if you and they can check ego's at the door, it is amazing what a recent college grad can teach you.

We had people on the XP team that had only marginal programming experiences.  For example, they may have been a classically trained pianist, so the think differently.  *THOSE* are the skills that improve the team.  "Why is that important?", "I don't understand."  "What would happen if we did this?"

The dynamics of PP force a better design.  You leave less debris behind.  The code is clearer; in communicates better.  I can forget a tremendous amount in just a few weeks.  So the clearer the intent of the code, the better I can change it as the system evolves.

I have certainly been in "The Zone" many, many times.  It happens in PP as well.  It's just happens out loud.  You have to develop the skill of thinking out loud.  Your partner has to be able to read your mind.  And you, hers.  It helps if you're friendly with each other, but I haven't been friends with everyone I partner with either.  You do have to be respectlful; that is hard sometimes.  But, it is also valuable input to the performance review.  The way to measure your value is to simply ask, "Is the room more productive when I'm in it, or when I'm away?"  Make the first happen; it makes it easier for you boss to pay you.

What kind of software have we developed?  It's ranged from IBM SNA protocol translators.  Device drivers.  Print stream conversion from IBM AFP and Xerox Metacode to flat text, PDF, TIFF and database indices.  It has been a large archival system for millions of documents per month.  It has been web pages for retreiving that data.  Currently, we're working on a large web-enabled fast food ordering system.

I have accomplished more in the last few years of real business value that I did in the ten before that.  Much of that comes from the other XP practices, but PP is an integral part of XP.  I won't give it up easily.

Tim Wise
Thursday, December 27, 2001

Our team tries to follow the "All production code must be written in pairs" rule. While we are not completely successful, much more of our code is written by pairs than not.

To answer the questions posed by Joe Bauer:

1) What type of software is being developed?

We develop in-house business systems. The systems are neither extremely complex, nor simple "GUI on top of a database" types. We often have hard implementation deadlines which stretch our creativity in managing project scope.

2) What type of management support do you have?

Strong. We were a new team building mostly new systems (some inherited code). All team members were recruited, knowing we would use Extreme Programming for most of our development, and that pair programming is a key practice. We never hire someone without a multi-hour on-site interview which includes pair programming with more than one team member.

Our experience is very positive. Our team varies from a couple of people just out of college to people with more than 20 years in the field.

Personally, I find pairing with less experienced developers hones both my mentoring and design/coding skills. I believe we (my partner and I) usually develop simpler and better code than I would have developed alone.

I find pairing with another experienced developer can be exhilirating. Contrary to some people's contentions in this discussion, there are two or three other people on our team with whom I can definitely get "in the zone". It's not always the case, but two seasoned developers can definitely be more productive together than working individually.

Is pair programming a perfect practice which works for everyone... No, we've had a few people who might have otherwise been fine developers decide our team wasn't the place for them.  Do I occasionally wish my partner typed faster... Yes. Does it matter in the long run... No, I don't think so. I think the teams velocity is faster overall, and typing speed is seldom the limiting factor in software development. If it is, then we should probably develop a tool to do the typing so we can work at a higher level of abstraction. Have we had individuals who had problems pairing with another individual... Yes, occasionally. This is when a good manager or coach needs to help the people involved work on their pairing skills.

Ten years ago I might have described myself as a "gun" who wouldn't enjoy pair programming. Today, it is my preferred mode for writing code other people will see. I still like to "explore" alone.

Douglas Swartz
Thursday, December 27, 2001

"As a developer of desktop applications for Windows, there are a lot of time-consuming, yet non-thinking tasks that have to be done."

It's easy. Every time when you do non-thinking task you do something wrong. It was always true in our experience - from coding to testing. If you do something boring - you have to find a way to avoid this. That's why Joel said you need "Smart" programmers.

I'm not saying this because I'm so wise. I'm saying this because I was so stupid to put the no-brain UI code everywhere and later I had to refactor everything and trow away hundreds ot thousands lines of code to make system simpler and clearer.

Roman Eremin
Friday, December 28, 2001

I asked Joel this Question on 8/30/2001
What are your thoughts on XP? (Extreme Programming)?

This was Joels Reply. I thought I would share it because it is so damn good.

I tend to be very skeptical of any methodology that claims to be a "silver
bullet"... I have consulted for a lot of companies on improving their
development process and every situation is very different. For example, one
of my clients had 12 inexperienced developers and 1 tester who was useless
and unfireable -- and no money to hire more testers. Needless to say, their
software quality was so low they were losing customers left and right.
Another company, about the same size, had 12 developers and no testers but
they were really, really good and tended to write bug free software (at
least, remarkably few bugs had been reported by customers in a long time, so
quality was not the most pressing problem as a business).

What would "methodologies" say? Both companies were very different,
sociologically and in situation. In both cases, making people adhere to SEI
or ISO-9000 type quality specifications, or using pair programming from XP,
would have driven people crazy, and possibly caused the best developers to
leave in frustration... which would have been much worse. In both companies,
taking the time to do SEI, ISO-9000/1, or even to learn and try XP would
literally have caused the companies to go out of business. And in both
companies, there were two developers who were very critical -- if they left,
the company would fail. So if those two guys didn't want to do pair
programming, there wasn't going to be pair programming, full stop.

What did we do? In the first case, to stop the bleeding, I convinced them to
stop making new releases every week, something which left no time for
testing. In the second case, we didn't really have to do anything, but we
did resuscitate a long-moribund automatic smoke test they had stopped
running, and appointed one person to maintain it. Not ideal but good enough
since their quality was really quite good.

Anyway, this is just one example of why cookie-cutter "methodologies" can do
more harm than good. It takes a while to get people to change and not every
methodology should be slavishly adhered to... that usually results in some
of the worst Dilbert scenarios. And smart developers tend to do great work
with no methodology, while bad developers tend to do bad work no matter how
much you force them into rigorous development procedures meant to prevent
bad work.

All the best,

Michael Lubrano
Friday, December 28, 2001

I have worked for the last two years in an XP environment and found it tremendously exciting.
I dont find PP at all intimidating or problematic, in fact it is often when I do my best work as I feel constant peer pressure to perform at my highest, despite this I did have some reservations and they all revolved around peopleware issues about being in the zone.
I recently had the opportunity to meet with Kent Beck and I asked him about PP in particular the following point about being in the "Zone". My question was with so much literature nowadays about peopleware and the measured advantages of non-interruptible time periods, how did this lie with an xp environment? I was particularly interested in understanding what happens when you interrupt a pair, do you lose 15*2? In Kent's experience interrupting a pair only diverted the attention of the strategist and not the coder and so there was no context switch for the coder so potentially "saving" time over a single programmer working alone. I must say I am not entirely convinced, 1. Surely for PP to make sense it is the strategist that shouldnt be interrupted?
Does anyone have any links to measurements about interrupting a pair?

Graham Cunningham
Friday, December 28, 2001

I have worked with varying degrees of pair programming, all positive:

Check-in buddies:
All check-ins arer reviewed by someone else who understands the code. This si good for bug fixes where having both of you spend the time reproducing and discovering the problme is silly, but the fix is often small.

This is where you talk through a problem with someone else, and often solve it yourself. The joke being that an aspidistra (a houseplant) would do as well, but of course it wouldn't, as you need the feedback (even if non-verbal) from the person listening.

Full-fledged PP:
I did this recently on a side project with a SmartFriend, and was amazed how well it went alternating at the keyboard and reading the changes to a complex algorithm together. Agaiin though, I had a working implementaion which we were improving.

Kevin Marks
Sunday, December 30, 2001

In XP we have the value - Collective Code Ownership and from business point of you this is a very good thing - one can leave or join the team without problems. Besides it ensures the quality of the code.

Another example - you have two programers project. If they do not use Pair Programming your need to spent a lot of time on communication and most probable your will have troubles with misunderstanding.

As from my experience Pair Programming is very efficient. Any case you should try it.

Yakov Sirotkin
Sunday, December 30, 2001

Some pair-programming Do's and Don'ts.

DO pair people of roughly equivalent programming ability.

Research (I read it in one of the XP books, but don't have it here to cite) shows you get the best benefits out of pair-programming when the pair are of roughly equal skill.

If the pair are unequal, then the better coder will spend most of the time typing, and the nexperienced coder will just look on, not say much, contribute nothing to the code, and learn almost nothing from it. Those (rare) times that the experienced coder gives the inexperienced one the keyboard, the experienced coder will end up dictating each line of code, which is just frustrating to both parties.

On a related note,

DON'T try to eliminate a bozo programmer by pairing them with a competent programmer.

You may neutralise the bozo, but at the expense of the productivity of the better programmer. You're better off pairing two bozos together, and giving them something harmless to do together.

DO swap positions often.

Pair programming involves one programmer being the "driver" and doing the typing, and the other being the "navigator" and keeping an eye on context. If you find you've gone an entire day without swapping, you're doing it wrong. Swap every few hours.

DON'T be afraid to ask for the keyboard.

If you're trying to explain what you're thinking to the driver, often it makes far more sense to just say "Here, could I drive for a while?" and show them what you're thinking in code.

DON'T be afraid to ask for an explanation.

If the driver has just written something that you don't understand, get an explanation immediately. If you're driving, and your navigator asks for an explanation, your first thought should be "That code isn't clear enough. I need to clean it up, or at least comment it, or nobody will understand it tomorrow."

DON'T skip breaks.

Often, if you're coding and you start feeling tired, you'll resist the urge to go for a wander around the office, and instead you'll just hand the keyboard over to the other member of the pair, and take the navigator's post. Resist the urge to start coding again immediately. Get up and grab a cup of coffee first.

A pair should be in constant communication, so DON'T stop talking.

DON'T force it.

I suffer from insomnia on occasion. When I have had a bad night, I always pair very badly the next day. Thus, when I've had a bad night, I try to choose a task that I feel comfortable doing without pairing. On the other hand, when I turn up to work with a hangover, I can still pair, I'm just more likely to spend the morning in the navigator's chair.

I also don't like pairing when I'm trying to figure out a new API, or when I'm working on a "spike solution" to a problem.  On tasks like that, I like the freedom to code in random directions, quickly, without having to explain my thinking processes to someone else. After I've figured the API out, or sorted out the spike, I'll call in another programmer to help do the real thing.

Charles Miller
Sunday, December 30, 2001

We first "stumbled" across pair-programming during a testing round where we found a lot of bugs and very little time to fix them. It is now a required part of our development.

Speaking personally, while I can say that I can work just as well on my own, whenever I've worked with someone else the quality of the work is ALWAYS much higher by all measurable means. 

Finally, I think the biggest key was alluded to by someone else; your team.  If your team gets along and doesn't have big egos (or the individuals can control them) pair programming is almost always a big success.

Chris Blaise
Monday, December 31, 2001

Pair programming is a bad concept - based on a few sound princples badly grouped.  It is not, however, the productivity panacea it is made out to be.  In fact, panacea are quite rare - as are exponentially intelligent developers, miracle hair growth formulas, and workable get-rich-quick schemes.  Sounds cynical?  Read on.
Try pairing up two programmers of any skill level for a few weeks and watch.  We have tested parts of XP in our office, and noticed some minor amount of good followed by a copious amount of marginal productivity.
Why you ask?  One keyboard, two brains, and two mouths.
Collaboration is good.  Menoring is good.  Communication is good.  But, if you cut the input bandwidth by 1/2, and double the use of cranium to cranium communication, all problems (on average) are solved more slowly. 
There are exceptions to rule ... pair two incompitent developers, and they may have a chance at solving a small number of problems very slowly.  But, smarter developers will solve many more problems better.
Trust me.  Anything touted as a wonderful, miracle cure to all software development ills is simply untrue.  Take a look at Rapid Application Development for a set of sound principles backed by ACTUAL STATISTICAL DATA, and not stories of success.

Bruce Alderson
Thursday, January 3, 2002

Who sais that XP will solve all issues?? Who's sais XP is a silver bullet?

I'm a sceptical XP fan; we do most of the xp-practises, but as always we use them with care. For example, extensive unit tests on some gui-screens didn't pay off for us. However unit tests on algorithms, even simple ones, are  definitively worth while.

In my experience XP will solve issues on a programming level for a group of about 2 - 10 programmers. At a higher level, e.g. project management, it can work but then the constraints on the environment are much harder to satisfy. (customer on side etc).

Regarding pair programming; we do it some of the time. Mostly for the complex code and when there is a time limit(!). Pair programming will give a better feeling of control of a project. However, for some simple code the quality improvement sometimes simply isn't worth it. Code can always be better, but can you affort it?

Thursday, January 3, 2002

Pair Programming definitely needs to be given a chance to work if it is to have any chance of success.  In our experience it took a while for all programmers to understand that as managers we were not going to let them get away with not doing it.  We wanted a valid test of the concept.  Once that got across to people we started to see the true results of Pair Programming

What were those results?  Much higher quality code, which resulted in many fewer QA failures and ultimately in a stronger product.  Many people here have pointed out that the coding does not go significantly faster with two people rather than a single coder, and I agree with that sentiment.  The only exception is when the code is complex.  In that case having two people looking at it often cuts time significantly.  I think the reason is that one person tends to keep the low level coding in mind, while the other tends to keep the high level data structure and interaction with other portions of the project in mind.  That combination makes the coding go faster in our experience.

The biggest thing we have seen with QA is a much lower failure rate, and when issues get fixed the fix is much more likely to be 100% correct.  Our metrics have shown that prior to Pair Programming we had about an 75% success rate on fixing problems correctly (ie, problem resolved, no other problems created).  After starting to use Pair Programming that number increased to 99%.  In our product QA time is significant, so decreasing it not only means the product is better, but also we have saved money and in the end the start to finish time on projects is often approximately the same as it was when we did single person programming.  Said another way, the gain in QA made up for the loss in time programming with two people.

It is very important that if Pair Programming is used that it is used by everyone.  It is important for managers to enforce it and model it for their teams.  We have found that when the managers buy into the system the people that work for them buy into it and maximum benefit is achieved.  We also have not seen significant differences in productivity based on the skill level of the people in the pair.  When used properly a high skill person often ends up mentoring a less skilled programmer, which then makes that programmer better next time around.  In effect, we believe Pair Programming is raising the overall level of the team, rather than lowering it to the lowest common denominator.  Highly skilled people are also forced to consider things a bit more carefully which has the effect of making their code better because it is less likely they will take the approach of "let me try this because if it doesn't work I can hack it this way..."  We tend not to hack around as much when someone else is watching and needs to understand what we are doing!

Pair Programming is clearly not for everyone.  I don't know how well it would work with very large teams (our team is under 15 people).  I do know that for our group Pair Programming made the single biggest difference in quality as well as overall project metrics.  It also made many people get "closer" and seemed to almost work as a team building exercise.  We do make it clear that Pair Programming is NOT optional, and we also make it clear that we expect the pairs to change often.  It seems to work for us and that's good enough for me!

Bob Hartman
Thursday, January 3, 2002

My experiences when pair programming have not been very positive until now.

Generally when it is done with people whose programming skills are (very) different it turns out that one person keeps writing all the code and the other just watches - so it is just like having 1 brain working at the cost of 2. In this case, pair programming is more like 'training on the fly' (I just hated it - hoping for code suggestions and instead receiving only approval nods even if the code was wrong moreover having to pause coding to explain every single command the other person wouldn't understand).

When done pairing people of equivalent skills, it generally does not generate results equivalent to two people working alone in parallel processes. And in several projects we usually lost a terrible amount of time, jeopardising our schedule.

Ricardo Shimoda Nakasako
Friday, January 4, 2002

Bob Hartman says that pair programming doesn't increase productivity but it takes the likelihood that a bug is truly fixed from 75% to 99%.  Looking at that, if you're fixing n  bugs and you have 2 programmers, and we assume for the sake of argument that it takes 1 day to fix a bug, pair programming will take n days, whereas single-guy programming will take (n + n*.25 + n*.25*.25 + ...)/2 days which asymptotes out at less than n.  So single programming seems more efficient, still.  (Although the frustration of bugs regressing is immense and almost seems worth taking a productivity hit to avoid...)

James Fristrom
Friday, January 4, 2002

I've never actually pair-programmed but I'm curious to hear how you have actually made it work so well that your buddy can literally grab the keyboard and start typing, productively, despite of different personal preferences of the tools used to write the code?

Whenever I've tried to help a co-worker with his code in a non-PP environment, I've always run into the fact that they have their code open in an editor I've seldom used or that they have a strange keyboard shortcut for switching into the window where they're running a test suite or their ergonomic keyboard is unnatural to me or they prefer a trackball to a mouse, etc.

I can imagine that a PP beginner could easily get frustrated by different editor settings used by the buddy, too small font size, white-on-black editor window instead of black-on-white, etc. If the co-worker prefers emacs, a vim user is completely lost. How about different shells, the shell environment settings, all the tiny shell scripts and aliases which help you manage files and so on? The window manager settings? A left-handed mouse? Monitor contrast and brightness settings? Where is my blue wrist support?

Can you force a pair to use exactly the same tools and settings all the time and still keep your best programmers in the company? At least I personally prefer companies which don't try to standardize your personal tools too much.

Have you made some arrangements where you can easily switch your environment when you grab the keyboard?

Or do you just switch the roles seldom enough so that wasting some time logging in as a different user, loading all the files your co-worker was editing, etc,  isn't a problem?

Has anyone done pair programming successfully with two computers; switching the roles would mean switching the computers, too?

Or are my views just too biased? Can one easily learn to tolerate a standardized workstation just like one can understand the benefits of using the same programming language, the same libraries, the same indentation style, a common version management system, etc, even if the choices made by your company don't happen to agree with your personal preferences?

Jukka Suomela
Saturday, January 5, 2002

I have a good friend who I've known for about four years and worked with for about three. We're both very competent programmers, me more on the pure programming aspect, him more on the design and human aspects.

He and I do a lot of projects together. Sometimes we work on the same code, and sometimes we work on different code. We tend to define who owns what, and whoever owns what's currently being worked on drives.

I love it.

I've worked on my own, and I find that when I do that I have a tendency to slack off and Web surf instead of actually working. When my friend is sitting beside me, I get a lot more actual work done in the day. Plus, his instant feedback is very valuable, and we can quickly architect anything extra we need because we have each other to bounce ideas off of. The stuff I write when he's in there is much better, too.

We tend to switch between pair programming and individual programming. If I need help, I'll pull him over and likewise. There's a "we're in this together" feel, and it has definitely pulled us together as friends.

When you get the right pair, the result is magical.

Anthony J. Mills
Wednesday, January 16, 2002

Pair Programming.

To be perfectly honest, the idea of Pair Programming seemed a very alien concept to me. I had always taken my coding endeavours to be the task of a lone person, totally focused without interruption, in short, not a team event.

I come from an environment which non-programmers would have found unbearably noisy, the computer room of a large engineering company, with the constant whir of hard drives and fans, the hum of multiple power supplies, noises which given enough exposure to were like music to the soul. The only interruptions were handled in code!

I was then moved to an office, with about thirty other people, and every other minute a telephone would ring, destroying concentration. Add to that the ‘new’ management ideas and wham, I have to work with another coder!

The first problem is style, layout-style. Everybody has their own way setting out code. OK, in the early days, you had no choice, COBOL didn’t allow for any deviation of line layout, much like PRG etc (oh to be bound by such ugly syntactical layouts).  The power struggle took almost two weeks before the young pretender was indeed shown the way of the ancient code guru (‘Brassido’ I like to call it) a pointer to Hungarian Notation, and my quick thinking in producing a ‘Programming Standards Manual’ and he would forever do it ‘My Way’.

The second problem is control. Not too difficult this one, it would depend on the old rule of ‘possession is nine tenths of law’, so first to work in the morning had the seat at the keyboard, and thus would control the rate at which work proceeded. But on the days I was second past the post, it was horrendous! The guy was simply too slow getting to the right point in code. Just imagine yourself, as Alec Guinness in Star Wars, the expression “Use the short-cut keys Luke” was permanently in my head!

The third problem takes a bit more explaining, in that it is purely personal. At the time I was angry, not with him, but at the management. How could they have done this to me? Paying two people to do something that I was supremely skilled to do alone, halving my responsibility, creativity and worst of all my thought process.

Then I moved onwards, to newer pastures, and found a couple of guys that I not only worked with side by side, but for seven years we changed jobs as a team, even vacationed together, not forgetting the Friday afternoon drinking sessions.

You are more likely to spend ‘quality time’ with your pair partner at work than you do with your life partner, I mean serious concentrating time, the type that leaves you mentally exhausted but on a natural high (It is easy back home, just listening to a few things at once, but never given true concentration to anything, like the TV. etc). You have to be entirely comfortable with your partner. You have to have no boundaries, no fears and be able to convey information with a single glance or gesture.

Pair Programming to me is like marriage, you simply have to gel or you may as well file for divorce.

Mark C. Richards
Sunday, January 20, 2002

Regarding the difficult of two users sharing one WIMP desktop machine...

None of these seem to me to be killers...

But they're worth addressing,  because they're the sort of niggles that folk can use to excuse themselves from a new way of working that they reckon they won't like, to avoid voicing their main objection - generally 'I don't want to work in pairs'. 

Personalised editor settings, for example...  it's lovely to have your own font/display colour/hotkey/macro settings.  It's possible to have this, and still swap the driver & navigator over every couple of hours.

You could for instance, standardise on a customisable editor, which allows user-preferences to saved and recalled at a moment's notice. 

But even better,  set the LAN/WAN up so that when a user logs on to a desktop machine - any of the desktop machines in the workgroup/department/project, s/he gets presented with his/her own desktop. 

This then takes care of window manager settings (and even individual choice of window manager, as the contrast and brightness of the monitor are generally configurable from window managers these days

Stored 'user identities' for desktops even make the swap from emacs to vim easy .

As for the physical changes required:

right-handed people and left-handed people pretty much always both use the same type of mouse.  Lifting the mouse from the right-hand side of the keyboard, and placing it down on the lh-side doesn't seem (to me) to be onerous. 

(Logitech used to make a mouse that came in lh or rh varieties - I even bought them for my department.  I wouldn't bulk-buy them again - because it does create a barrier to easy 'hot-seat' at the desktop machines). 

As for the blue wrist-rest...  if it's yours, take it with you when you're going on a 'drive'.

Gordon Love
Tuesday, February 12, 2002

I am a graduate student conducting a research on Remote Pair Programming.  I have post an online survey which can be accessed from the    under research or directly accessed at .  The survey only has 10 questions and should not take more then five minutes.  The survey is focused on those who have tried both pure pair programming and remote pair programming so please tell us about your experiences. 

Your contributions are greatly appreciated.

Mazen Zari
Wednesday, April 3, 2002

I've tried pair programming.  In fact I am doing it now.

I think the cases where pair programming doesn't work can be solved if there is a good coach around who knows how to bring out latent communications skills hiding in seemingly quiet developers.

I have witnessed the "quiet ones" become more openly engaging of peers with proper encouragement.  Often times it is the continued seclusion that drives some of us deeper into our seclusion.

Pair programming puts more healthy pressure on getting us to communicate.  And so even if we can't do it all the time we still strive to do it all the time.

Regarding that "zone"; well...  I am now starting to see an entire team enter a "team zone" all at once every day of the week.  It really is an amazing transformation.

Try it.  You might like it.  But it will be a rough adventure if you can't figure out how to get the communications skills out of the individuals.  Hire a "team builder" for a day.  Team people how to act like a team.  I did.  It seems to have helped my team.

Eric Newhuis
Thursday, February 6, 2003

I meant to say "teach people how to..."

Eric Newhuis
Thursday, February 6, 2003

*  Recent Topics

*  Fog Creek Home