Mark Needham

Thoughts on Software Development

Pair Programming: So you don’t want to do it…

with 8 comments

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 silence

The 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 silos

Another 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 code

The 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 Summary

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

Be Sociable, Share!

Written by Mark Needham

June 8th, 2009 at 5:05 pm

Posted in Pair Programming

Tagged with

  • http://blog.rayapps.com Raimonds

    If you are discussing with your pair all the time and if all the time somebody is shouting in the room asking for help then programmers are being disturbed all the time and it is very hard to get into “the flow” to get the highest productivity level.

    Therefore I don’t agree that pair programming is better in all aspects compared to programming in silence in private office. I prefer to have both private time and then from time to time to discuss and review code with collegues.

  • http://azurestuff.com Erik Wynne Stepp

    I had never done formal pairing until recently. I was always open to it, but it was not part of the culture in most companies that I had worked for. I was also a little skeptical like Raimonds that it might be difficult to get into “the zone” with all that noise going on.

    A few months ago I had the opportunity to do formal pairing on a project, and I found that in actuality, it is much easier to get into “the zone” when you have someone there with you to help you focus.

    While pairing, I found that my productivity increased and I was in “the zone” for the entire time while working with my pair.

    Perhaps those who have not paired should try it for a week or a month and then decide whether or not this will help them achieve their highest productivity.

  • http://devblog.petrellyn.com Jamie Phillips

    Although I have not practiced “formal” pair programming (i.e. as part of a formalized process); the times that I have had impromptu sessions have been very rewarding from a technical point of view and from a shared knowledge point of view. On the occasions that I have been located in an open plan office or cubicle farm it has helped a lot to book a meeting room and “disappear” for a few hours – that way you ensure that you and your pair can work in isolation “off the grid” and therefore reach the nirvana so sought after by mere mortals.

  • Harry

    Totally agree with Erik.
    Pair programming, like many other things in XP, is something that you have to try it to see its benefit. The good thing of pair programming is – it has lower technical learning curve to start, compared to TDD. The difficult part is to persuade those who sit in the corner offices. …

  • Alex

    I work in a very small team, that used to consist of 2 developers (including myself) and a team lead (also developer but has a lot of extra responsibilities). At that time I was pairing a lot with the other developer and found it very beneficial. Unfortunately, one day the other developer left the team, leaving only me and the team lead. I found that pairing was not feasible anymore, mainly because the team needed to be able to focus on more than one thing at a time, and its disruptive to pair with someone who has to go to lots of meetings everyday.

  • Pingback: Dev Blog AF83 » Blog Archive » Veille technologique : Microsoft, Organisation, Ruby, Rails, PHP, Langages, Sécurité

  • Pingback: Pair Programming: The disadvantages of 100% pairing at Mark Needham

  • Pingback: Pair Programming: The disadvantages of 100% pairing | Java Code Geeks