bgeek.net

In a forthcoming book (before you ask I've no idea what the title is) there's a little case study about the first project i ever truly worked on as a developer. The project and the team have some of my fondest memories, and I'd want to work with any of the people in the small team i worked in.

One of the things that made us such a close knit group was forcing ourselves to spend an awful lot of our time pair programming. The value from this is actually too large to describe, although there is an immediate draw back that means I've not really been able to find a work place that encourages it as much.

• Working closely with each other is actually very good for morale. It makes you want to go to work and help out your friends.



• No knowledge is held by just one person, all decisions are made by two and all work is done by at least two.



• There's a lot less head scratching time, with two people ideas can be bounced around quickly, and only the important, hard to decide factors are "sent upstairs" to decide on. Also if one person looses track, the other will generally be able to prompt.



• Mistakes are weeded out early

I can't speak highly enough of pairing, although it takes a lot of buy in. However there are moments when pairing can actually be quite tiring and frustrating. We found moments when both sides of the pair wanted to get work done quickly and were in "the zone" we actually preferred to split up for a while and work separately. We called this the "Split and Sprint".

The moral? always be pragmatic about your techniques but realise the value in what you have. We always came back to pairing, both of the pair would eventually tire and need the support of the other to check over work/tests or just to give them a point in the right direction.