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 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.
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.
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.
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.