· pair-programming book-club

Book Club: Promiscuous Pairing & Beginner's Mind (Arlo Belshee)

In this weeks book club we discussed Arlo Belshee’s paper 'Promiscuous Pairing and Beginner’s Mind' where he presents the idea of rotating pairs more frequently than we might usually, suggesting that the optimal rotation time is 90 minutes.

I remember coming across the idea of promiscuous pairing a couple of years ago but I hadn’t read the paper all the way through and so far haven’t worked on a team where we’ve really tried out his ideas.

These are some of my thoughts and our discussion of the paper:

  • I found the section of the paper where he talks about skills and competencies quite interesting - the suggestion seems to be that for any given task the least skilled person for that task should be the one to do it but that the person should still have the necessary competency to execute it. I’m not entirely sure of the distinction between skills and competencies - Belshee suggests:

    The difference is simple. People can learn skills in a matter of months. People can’t learn competencies in less than several years. There aren’t many things that fall between — qualifications are almost always skills or competencies.

    Software development wise this would suggest that a skill such as object orientation would be more likely to be a competency but what about a specific programming language? It is possible to learn your way around a language to the point where you can do some productive things with it relatively quickly but for me at least there are still things I don’t know about in the languages I work with and I’ve used some of them for a few years now.

  • There is a nice quote from the paper when discussing the idea of giving tasks to the least qualified person, that 'the least qualified teams produced the code that had the fewest surprises' - I imagine this is probably down to the fact that the least qualified person probably doesn’t yet know how to do clever things with a language so they just do the most obvious implementation. I think this is certainly what we want to happen when a team is working on code together.

  • I liked the discussion of beginner’s mind where he talks about it being a transitionary state that we move into when are in a situation that is unfamiliar but near the limits of our comfort zone and that we will move out of once we are comfortable with the current situation. It seems like this state of mind links quite closely with the idea of deliberate practice that Geoff Colvin talks about in 'Talent is Overrated' - the idea being that in order to improve most effectively we need to be doing activities which are just beyond our current competence.

  • I’ve frequently noticed that people are reluctant to swap pairs until they have finished the story that they’re working on - Matt Dunn pointed out that this is probably linked to human’s natural desire to finish what they’ve started! Belshee seems to get around this problem by ensuring that the tasks being worked on are sufficiently small in size that they can be completed within one or two pairing sessions. A lot of the work that we do is integrating different systems where there is quite a bit of exploratory work to find out what we actually need to do first - it would be interesting to see if quicker rotations would be appropriate for this type of work or whether a lot of time would be spent bringing the new person on the pair up to speed with what’s going on.

  • We had some discussion on pair programming in general - Raphael Speyer described the idea of 'promiscuous keyboarding' as an approach to try within a single pair. The idea is that the keyboard switches between each person every minute which hopefully leads to both people being more engaged. I find that quite often on teams people will roll in and out of pairs when there help is needed on something - Nic Snoek described this as being 'guerilla pairing' and I think it is something that a technical lead of a team is most likely to engage in as they move around the room helping people out.

I often feel that pair programming is a skill that we take for granted and we assume that we can just put two people together and they’ll be able to work together effectively.

From what I’ve found this doesn’t always work out so I think it’s important to keep innovating and trying out different things in this area so that we can find approaches that allow us to work better together.

Update As Dave suggests it should be 'guerilla' and not 'gorilla' pairing that Nic suggested as being a useful idea.

  • LinkedIn
  • Tumblr
  • Reddit
  • Google+
  • Pinterest
  • Pocket