Pair Programming: So you don't want to do it...
I’ve worked on several software development teams over the last few years - some that pair programmed all the time and some that didn’t - and one of the key things that I’ve noticed is that the level of collaboration on these teams was significantly higher when pair programming was being done on a regular basis.
The following are some of the observations I have noticed in teams which don’t pair program frequently.
A culture of silenceThe amount of communication in a team which doesn’t pair is almost by that very definition going to be lower than in one that does - you don’t have that almost constant dialogue/discussion going on that you get when a pair are at the keyboard since everyone is head down coding in their own little world.
A consequence of this is that other types of communication are also reduced.
When a room is full of people pairing it’s not uncommon for someone to shout across the room for a colleague to come and help them and their pair with something. Since there is already a lot of communication going on this doesn’t feel that unusual and since other people in the room might hear us speaking we can also get the benefits of osmotic communication.
When we don’t have that it feels very awkward to do this and in fact often the person you call won’t actually hear you since their head is down and focused on the task their working on.
The inclination the next time you need help is to just work it out yourself, further harming team collaboration.
Code silosAnother consequence of having people working alone is that people become very specialised in certain areas of the code base and then when they either leave the project or are ill there isn’t anyone else who knows their area to work in that area of the code.
It becomes obvious that we have silos in the code base when code starts to be referred to as “X’s code’ or ‘X’s way of doing things”. Another danger sign is when there is a lot of talk about “handovers” - a sure sign that collaboration hasn’t been taking place.
One way to address this problem without pair programming is to mandate that code reviews must be done before code written alone is checked into the source control system.
The problem with this is that there isn’t really way to enforce it if people don’t want to have their code looked at by someone else beyond reverting their changes which seems perhaps over confrontational.
Repeated codeThe tendency to end up with several people solving the same problem is one that rears itself quite frequently when people are working alone.
Since each developer doesn’t have as much visibility into what their colleagues have been working on - the sharing of knowledge that pair programming encourages is absent - we often end up with several sub par solutions to the same problem instead of collaborating to come up with one good solution.
Repeated code is perhaps the biggest waste of any developer’s time - we are adding no value at all by doing it and are creating confusion for our colleagues as they now don’t know which bit of code is the correct one to use.
In SummaryI’m sure there are ways to overcome these problems but I’ve never seen it done effectively without having people working together more closely.
I’d be interested in hearing ways that others have created collaborative teams without having developers collaborating closely by using a practice such as pair programming.