One of the biggest arguments used against pair programming is that we get half as much work done because we have two people working on one computer.

Even if we ignore the immediate flaws in that argument I think this is a case of looking at individual productivity when in fact what we really care about is the team’s productivity i.e. looking at the local optimisations instead of the big picture.

I’ve worked on teams which pair programmed the whole time and teams where pair programming was less prevalent and the difference in how well the knowledge of the code base was spread throughout the team is massively different.

When you have developers working alone knowledge sharing is much lower - people tend to become quite specialised in one area of the code meaning that the next time there’s work around that area they do it and so it spirals on and on until you’re completely reliant on them. If that person is then ill for a day we have a big problem doing any work in that area.

There were 8 different types of waste described in the presentation:

When people are working alone they may try to pass on their knowledge to others in the team but it’s never as effective as if the other person has worked on the problem with them at the same time - there is always some information lost in a hand over - the waste of internal transport.

In the event that a person with a lot of knowledge in a certain area of the code base is ill then someone else will end up having to pick up where they left off and learn how the code works from scratch - the waste of over processing. This applies beyond just the simple situation where someone is ill - when pair programming is not being practiced people have less idea about the problems their colleagues have already solved since the benefits we would normally achieve by rotating pairs are not achieved.

Research suggests that pair programming can lead to a reduction in defects in the code produced due to the fact that we always have two people looking at the code. I think this is only true if both people in the pair are engaged - if one person isn’t then I can’t see how the defect count would change compared to having people work alone.

One of the other benefits I have found with pair programming is that it really makes you think about the value that you are adding by writing a certain piece of code. I think we are much less likely to gold plate with two people at the computer rather than just one. We therefore don’t end up with unnecessary extra features which don’t really add that much value to the customer.

When it comes to task switching I think this will always happen to an extent within a project team - people are often called away from the story work they are doing to help out with something else. When they are pairing this isn’t as disruptive since their pair can continue working on the problem until they return. If people work alone then the story work will end up on hold until they return and take the time to regain the context to continue.

It’s arguable but I’ve noticed that due to the extra discussions that happen when people are pair programming there tends to be more focus on ways to improve the way that things are being done, be it the way the code is being written, the way the tests are designed or the processes being followed. I feel pair programming encourages employee creativity which can only be a good thing as far as I’m concerned.

I can’t think of any obvious ways that pair programming would reduce the other two types of waste but I find it interesting that the majority of them are covered.

This was just a brief look at what I consider to be one of the most effective team learning tools available to us from the angle of a methodology which recognises that learning quickly is important for successful delivery of software projects.

Every time I see pair programming not being done I become more convinced of its value.