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

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

What about the costs?

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

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.

Resources