The Costs & Benefits of Pair Programming
Excellent article on pair programming, a key feature of Extreme Programming - XP. It set me thinking about the wider implications for knowledge work. The claimed benefits are:

* fewer bugs so cheaper overall
* more fun
* people learn best practice from each other
* project gainst robustness can can survive losing people - (nicely put as upping a project's 'truck number' - how many team members must a truck hit to take out the project?)
* programmers can 'tag wrestle' problems so that as one person't energy fails, the other can take over.

For me, as a KM practioner not working with software developers, I'm wondering where else it could be applied. I've had some great 'lock yourself in a room with a colleague' sessions. But these involved us working in parallel on different parts of the same task. Benefits were easy communication to clarify ideas, align interpretations and help out with blocks. They also reduced my tendency to find distraction tasks whenever I get stuck just out of a sense of social obligation. However, I find, say, drafting an e-mail with somebody else at the keyboard excruciating. I'd only do it when absence of errors and immediate consensus were so important that it was worth the agony (memo-type e-mails have to be right first time).

The article also makes a link to apprenticeship and the legitimate peripheral participation concept of Lave and Wenger. If you consider non-IT work there are some good examples. It'd be quite natural for the apprentice salesman to work with the old hand on a pitch, for example, or think of apprenticeships in plumbing, building etc. What seems to be the barrier is that knowledge-workers are wedded to the solo-user norm of IT interfaces.