Pair programming LTD

Pair programming is often recommended as one of agile techniques that help improve productivity, team chemistry and code quality. Unfortunately I have never seen it actually work the way it is described – two people sharing a desktop writing some code full time together. There is always something that prevents this happening.

For instance, developer A is very quick, write-it-first-than-think-about-it style. Developer B is more of the ok-lets-think-twice-before-we-press-a-button style. Both are good in their own way, each one can develop the feature in question in more or less same time and quality. Try to combine them together? Not so good. If B drives, A becomes bored and loses interest quickly. If A drives, B gets nervous and loses track of what’s going on.

If you say, well, just organize the team so that the people have same style, I am not going to agree with you. 🙂

Diversity is good, as long as people are willing to work together (very important), different skill sets and styles are useful – some task are better suited for one or the other. And besides even if both developers were twins, there are still a bunch of factors that make pair programming difficult – outside interference, workstations not optimized for pairing etc.

So instead of “classic” pair programming we do a “limited” version of it. Well, the goal is to keep the collective ownership on the code (or at least on the tasks that do require it – not all bug fixes need to be looked at by two people for example). How it works? It’s very simple. Each “important” task is assigned two developers that are responsible for it – but we do not tell them that they have to work in pairs. Instead they are free to decide themselves how they want to split work. (BTW, this really emphasizes bottom-up style of agile). Some larger tasks may have even more people assigned to it.

So what follows is that the mini-team will some brainstorming together about the task AND the best way to accomplish it. After the main details are discusses and agreed they will usually split the actual mini-tasks and work solo and then integrate them together. For us this gives all the benefits of pair programming without the drawbacks and without the need to force people to “sit together”.

What do you think? Have you participated in long term pair programming teams? Or similar approach to ours is used? Anything else that can be done to improve it? Use the comments 🙂