Thomas Sundberg

June 15, 2012

Pair Programing

This post has been migrated to

How do you solve a problem best? In your solitude alone or in a group? I know that I solve problems better in a group. The group has to be small so you don’t get disturbed. But it has to be large enough so a discussion can occur.

Programing is not about writing text fast. Typing is never the bottleneck when programming. The bottleneck is problem solving and solving the right problem.

Pair programming is about two persons that solve a problem together. Problem solving in a group tend to result in better solutions. Different people see a problem from different angles. The result is usually better than a solution that one person came up with.

This is my experience from working as a teacher at the leading technical university in Sweden. Students that solved a programming assignment in a group usually had better solutions than students that worked alone. The group size is important. Three persons could work. Four persons never worked, there were always somebody who hadn’t understood. The best size was a group with two persons, a pair.

It is also well-known among practitioners of pair programming. Unfortunately less known among people who don’t work with problem solving, programming or similar.


Why should you do pair programming? There are a number of reasons:

  • Solving the right problem – two persons that has understood the problem has a better chance to solve the right problem and not the problem one person has misunderstood.
  • Quality – the co-driver will assist the driver to develop the algorithm and act as a guard against mistakes.
  • Knowledge spread – both participants in the pair will have a great knowledge about the solution when it has been developed in co-operation.
  • Constant code review – instead of having code reviews from time to time you have them all the time. The co-driver will constantly review the code that is being written and suggest improvements.
  • Reduced costs – bringing new developers into the team is expensive. If they are brought in using pair programming then they will learn fast and can soon be productive. A new developer is productive within minutes instead of weeks or even months.
  • Single point of failure – what happens if only one person knows about a certain area of the code and chooses to quit or has an accident on his way to work? Keep your bus count higher than 1. The bus count is the number of buses needed to erase the knowledge your team has.
  • Spread knowledge about the tools being used – every developer knows something different about the development environment and will therefore constantly learn new things from his partner.
  • Discipline – it is really hard not to focus at the task at hand while pair programming. You will therefore get more work done.
    • Focus – your partner will ensure that you focus on the task at hand and not a random page on the web.
    • Direction – your partner will act as guide to ensure that you don’t stray away from the proper path by accident.

What about the costs?

Before dismissing pair programming due to cost reasons, calculate the cost of

  • Bringing a new developer into the team
  • Long feedback loop from code review
  • More bugs due to individual mistakes
  • Solving the wrong problem
  • Solving the problem the wrong way
    • Making the code untestable
    • Adding dependencies to the environment
    • Adding test last

The cost may seem to increase with 100% when two developers are working on the same task. But given the speed, the increased quality and the focus to solve the proper task it actually just increases with 15% according to Cockburn and Williams.

Two types

Driver Co-pilot

A driver that writes the code and a co-pilot that keep an eye on things. Each person will have the same role for an extended period of time. It is however important to switch roles sometimes, perhaps every 15 – 30 minutes or so.

Ping Pong

Switch roles very often. The driver starts with writing a test. The roles are then changed and the new driver implements the production code and the next test before the roles are changed. The changing of roles should happen often, perhaps every 3 – 5 minutes. This forces the pair to take baby steps forward. It happens that I hear developers claiming that it is cheating to take baby steps and perhaps start with a hard coded answer as the production code. I claim that it is not cheating, it is just taking small steps forward and very careful making sure that the solution is correct.

Sustainable pace

No matter how long time you work in the same pair, always make sure that you take breaks. Working in Pomodoros of 25 minutes may be something you could try. Take a 5 minute break every 25 minute and work very focused when you work. Take a longer break, maybe 30 minutes, every fourth Pomodoro.

Pairing is hard work, you are always fully concentrated. It is impossible to pair if one isn’t focused and is doing other things. When you work alone, nobody ever knows if you were thinking on something else than the task at hand or something else.

Switching pair

How often should the pairs change? It depends of course, a figure that often is mentioned is every 90 minutes. That seems to be enough so that the pairs have created stuff but not yet grown tired of each others.

Always pair?

Should you pair program for the entire working day or just a portion of it? This is a difficult question and the answer must be that it depends. It depends on your colleagues, it depends on your management and it depends on the problem. I would suggest that you aim for half of the working day to start with. This may be changed either up or down. My experience is that pairing the entire working day is extremely tiring and that not every developer thinks it is a good idea.

Remote pair programming

Pair programming is best done with the pair at the same location. This is sometimes not possible. How can pair programming be done remote?

One simple setup is a voice channel using Skype, screen sharing using TeamViewer and file sharing using Github.

So by talking to your partner over Skype and at the same time share the desktop on one of your computers you will be able to pair program remote. File sharing may be nice but is actually not necessary. One problem I have experienced is when you have a need for scribbling a model on a piece of paper. That is hard when your partner is somewhere else. You can use tools like Google draw and scribble, but it is really difficult and a lot harder compared to a quick drawing on the back of an envelope.

Has this setup been tested? Yes it has. I have done remote pair programming from Finland and Sweden with a friend, Alexandru Bolboaca, in Romania. It worked very well. Our only problem was that we did it late at Friday evenings, our families had some opinions after a few hours and we were tired after a week of work.

A social activity

Pair programming is a social activity. Most of us developers didn’t become a developer for the chance of socializing with our colleagues. It is actually very common that we enjoy working alone and solve the problem without interference of other people. This is something that must be taken into consideration when introducing pair programming. However, in my opinion the up-side of pair programming is larger than the downside of it.

Not a goal

It is important to remember that pair programming is not a goal. It is one tool, of many, for solving the right problem better.



  1. Hi Thomas, thank you sharing your set-up for remote pairing. (It reminds me that we wanted to do some kates together…) One question, are there any things to pay attention to when setting up TeamViewer? I don’t want to expose my machine to the evil internet too much😉

    Comment by Peter Kofler — June 16, 2012 @ 22:24

  2. Finally finished my own post about the style of our remote pair practice. Thank you for your help.

    Comment by Peter Kofler — August 11, 2012 @ 20:56

  3. Good point.
    There is a nice Science paper about that “Evidence for a Collective Intelligence Factor in the…”.
    Apparently, communication, and not the sum of intelligences, is the key factor

    Comment by otsoa — July 2, 2013 @ 07:36

    • Hi!

      I didn’t know of that paper. I am, however, certain that it is the communication part that is the most important. Not to have two clever persons sitting together.


      Comment by Thomas Sundberg — July 3, 2013 @ 09:44

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at

%d bloggers like this: