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.

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.