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.
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.
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.
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.
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.
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?
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.
- Challenging requirements – solving the right problem
- Bus count – also known as truck factor
- The Costs and Benefits of Pair Programming – Alistair Cockburn and Laurie Williams
- The Pomodoro Technique – Working focused
- Skype – a tool for a sound channel during remote pair programming
- TeamViewer – a good tool for sharing screen and keyboard during remote pair programming
- Github – a simple way to share code when doing remote pair programming
- Thomas Sundberg – The author