Pair Programming in Retrospect

I’ve been doing pair programming for two years now. During this period I gained a lot of experience, so it is time to do a little retrospective and organize these experiences. I hope that you find something useful here, or even better, you may start to do pair programming.

Basics

Pair programming is one of the 12 core practices of eXtreme Programming in which two participants sit together and do programming using one computer. One of them owns the keyboard, while the other one assists. They are continuously discussing how and what to do.

What Worked for Me

After trying out several different pair programming styles, I’ve come up with a list of things which worked out quite well for me:

Use the same development environment as the others
Close all applications except the development environment
Pick a pair for the whole day and do not switch pairs during the day
Do pair programming only the agreed amount of time
Work with different people during the week if possible
Change roles (keyboard owner and associate) frequently, at least once in every 30 minutes, but never in the middle of the TDD cycle
Be honest, communicate a lot and be cooperative and patient

Imagine that you have to drive your neighbour’s car. Even if you are a good driver, it will be difficult, because the perspective is different from this car, this gear is automatic while yours is manual and the list goes on. The same applies for development environments, but it is easier to make them more alike. Use the same editor, editor layout, keyboard layout as the others.

Changing pairs is important, but too much change can make your day very difficult. It is very hard for people to adapt. Based on my experience one adaptation it is enough to do it once for a day. If you change partners several times a day, you have to adapt a lot, which is not healthy, believe me. I don’t have any facts, it is just experience. So find yourself a good candidate, work through the day and try to give and learn as much as possible.

On the other hand, if you work with the same person for days, you miss the opportunity to learn about what the other team members are doing, and more importantly, how they are doing it. So change pairs on a daily basis. Of course, if you would like to finish an already started task the next day, it is fine, but don’t stay too long.

Pair programming is about collaboration. If you just sit there and code while your colleague is watching you and you don’t communicate with her, then you are doing it wrong. Pair programming is about communication.** Talk to your colleague the whole time**, share your thoughts even if you think that they don’t matter. This will make the session very effective. Additionally, do not own the keyboard for hours, because your partner will lose interest very soon.

Talking and collaboration make pair programming very exhausting.** Do not do it for a whole day**.

Benefits

If you have the assumption that pair programming is time consuming, then you are probably right. It takes more time than working solo, but on the other hand it has advantages too:

The code produced during pair programming will be less buggy and the overall code quality will be better
Pair programming is an effective way to share knowledge
It improves social skills

Why the code will less buggy? It is a fair question, isn’t it? Unfortunately the answer is a bit complex. The code won’t be better just because more people are working on it at the same moment. One programmer can achieve great things, so can two programmers, but the opposite is also true: one programmer can make mistakes, and two programmers can make them, too.

Based on my experience, when two programmers are working in pair, at least one of them always wants to do the right thing. One doesn’t want to cut corners, one doesn’t want to implement workarounds, one doesn’t make compromises on quality. To prove my point, I did a small experiment. I observed two programmers who worked together exactly the same way as I described before. After they got separated and worked alone, they started to write less test cases, no TDD, just ugly hacks.

I don’t know why it works like this. Maybe it has something to do with shared responsibilities or people feeling that they can achieve more in a team (in this case the team consists of two members). I have no clue at the moment. As soon as I find it out, I’ll update this article.

Back to the quality issue. Joshua Kerievsky told me once that it is forbidden in his company (Industrial Logic) to commit code, which was done solo. They did an evaluation and found out that a significant amount of bugs were introduced during solo programming. He has been practising agile methods for eleven years now, so he knows what he is talking about.

Interesting Scenarios

I had some interesting scenarios in the past. Let’s have a look and see what one can learn from them.

The Tale of the Two Keyboards

One of my former teams was international, and my friend had to work with a Swedish programmer. They understood each other perfectly, the language wasn’t a problem. But the Swedish keyboard layout really differs from the English layout and from the Hungarian, too. Do you remember that I mentioned the same development environment issue? It was a good example. Changing the layout using the features of the desktop environment wasn’t really enough so they used two keyboards with different physical layout. It was a brilliant idea. Everyone could use his keyboard with the well known physical and desktop layout.

The lesson: use everything available to support the pair programming. Even the silliest idea can improve the actual situation.

Two Towers

Once upon a time there were two very experienced programmers. Both of them had a solution for a certain situation, but they were so arrogant that they did the following. During pair programming after one finished his part, the other reverted it, and did it on its own. After changing keyboard, the other programmer reverted one’s work and implemented his idea. They went quite far: after one left the office, the other implemented his version again. After wasting two days, they realized that this won’t work, so they started to work on something else separately.

The lesson: if you have the slightest doubt that you cannot work with somebody else, then raise your voice and do something about it, don’t risk the project.

The Wise and the Arrogant Loners

One of my friends really preferred working alone. He did a great job, but pairing wasn’t his thing. He never told it directly, but very wisely he indicated it using small hints. He very rarely went to somebody for pairing up, but always said that if somebody would like to join him, they were welcome.

On the other hand, I worked with a guy who had great knowledge, but unfortunately he was aware of it, and acted accordingly. It was really hard to work with him. He rarely gave up the keyboard and after a couple of weeks nobody wanted to work with him.

The lesson: if you aren’t a fan of pair programming, give it a try, and if you still have problems with it, tell it to the others, and I’m pretty sure that they’ll respect it.

Temporary Separation

My colleague and I worked on a new code base, and it went very well until we faced a problem. We didn’t know how to solve this particular problem. We started to google it together, but we don’t read at the same speed, so my colleague gave up after 10 minutes and switched on the auto-pilot. He was just sitting there, and I was so busy with the digging that I realized it too late.

The lesson: if you face a problem, it’s better to investigate it separately and re-join afterwards.

When Pairing is Not Good For Quality

Two of my colleagues were working on a piece of code together. They did a good job based on their actual knowledge, but they missed an important refactoring possibility. They solved the problem using what they knew at moment, but in retrospect, they missed something.

The lesson: pair programming is great for solving problems, because two mindsets are present, but if none of the participants are aware of a certain technique or solution, they won’t find it out together either. Ask for code review after pairing up.

Static Tasks

A couple of months ago we had to perform very similar tasks in a sequence. We did the first one together, but afterwards we split up and did the same task separately. We doubled our speed, and when all the tasks were done, we reviewed each other’s versions.

The lesson: if the very same tasks have to be done one after the other, they can be done alone, but ask for a code review.

An Example

I looked around and found a great example of a pair programming session. James Shore and Roy Osherove worked together on a piece of code. The screencast of their work is available here.

The Next Step

I’ll go out and spread the word. Wish me luck! :-)