Dec 12 2008
How do you decide when to pair program?
At the XpDay 08 conference today, I participated in a workshop on pair programming organised by Matt Wynne and Laura Plonka. The participants were spit into several groups, discussing various challenges for the adoption and implementation of pair programming. I was in a group which was given a task to come up with the answer of when pair programming is appropriate.
The discussion that followed turned out to be very indecisive. Some people thought that pair programming is appropriate for all the tasks, whenever a line of code was added, removed or changed. Most people argued that pair programming is not always justified, for example for mundane tasks or for simple tasks where the second pair of eyes does not really bring any benefit. We tried to define it more precise, but every time someone came up with an example when pair programming should not be applied, someone else presented a different view. We ended up agreeing that code refactoring and cleanup is something that pairs should do in all cases, but for any other tasks we did not have a general agreement. Drawing a precise line when to apply it and when not turned out to be virtually impossible.
On the end, we came up with a proposal to start pairing on all tasks, and then five or ten minutes later decide whether the task actually justifies having two people to work on it together or not. That way we turned the question upside down. We concluded that we should not really think of deciding when to pair program, but splitting the pair temporarily if they both agree that for a particular task there is no benefit.
see more news from xpday 08
 |
 |
How do you justify to those who pay for projects the value of programming in pairs?
Lower error rate, lower amount of time spent by these people checking email, surfing, etc. Higher skill transfer rates. Improved team cohesion. there’s studies all over the net proving pairing works.
Simon asks “How do you justify to those who pay …”. The answer above, while accurate and one with which I agree, seems to place us in a defensive position and makes me anxious as a result.
I think we need to consider this deeper, as we should also question *why* we are justifying how a software team might work together. The need to justify IMO is a smell of mistrust, one which we often have with the gold owner due to legacy, or industry or company practice. I’d rather seek to justify this by building the trust, by asking the payer to look at the product/results and to examine the business value.
Aside, sorry I missed xpday08, as one of the founders I regret not taking part this year. Good to see some in-depth discussion, I hear the open sessions were a hit.
I worked in a shop that advertised itself as “agile programmer’s heaven” where all developers were forced into Pair Programming, whatever task they were working on.
It meant sometimes one developer would be just sitting reading some technical articles on his laptop. This is great but there isn’t the all important sense of achievment…
Added to that, the development manager thought it was a great idea to control how the development team allocates itself the tasks (we were using Mingle which I thought was pretty good) and would sometimes disband pairs or make them work on other tasks, and that would happen sometimes several times a day!!!
Needless to say, the team started with about 5 contractors and now there is only 1 left.
Very interesting!
I certainly agree that people shouldn’t pair when they see no benefit, but I also think that novice underappreciate the long-term benefits of pairing, so I’d encourage people to give pairing a serious try over the course of weeks, not just an afternoon or two.
If a team has a lot of mundane tasks that don’t really require high quality or much thought, I think they should ask themselves whether they’re working at the wrong level of abstraction. The whole point of software development is to take mundane work and give it to machines, as they’re both better and faster at it.
Personally, I pair all the time when I can. If something is boring to work on, we automate the boring parts so we can work on the interesting parts.