If Code is Written Solo in a Forest, Does it Make a Sound?

I’ve written before about my views on the importance of pair programming as a way of building a common conciousness in a team. When two people work on a piece of code together, not only is it instantly reviewed for correctness and readability, but already two people on the team understand exactly why the code is like that – the design decisions and trade-offs that went into building it that particular way, and are aware of any re-usable modules, patterns, idioms or conventions that emerged during the coding session. When each of those people goes off to work with other members of the team, those memes propogate around the room surprisingly quickly.

When you write code alone, you immediately lose this benefit, and on a system of any significant size, this is really important. You might be writing terrific code, making great decisions and innovating really creatively, but if nobody on your team has experienced those decisions and innovations with you as they happened, all you are really sharing with them is the much more shallow end result: the code.

It’s almost like they never even happened.

Agile / Lean Software Development

Comments (0)


XP Day 2008: Debugging Pair Programming

At XP Day 2008 I proposed an open-space session on pair programming. Specifically, I wanted to explore the reasons why programmers might not want to pair, or find it such an unpleasant experience that they’re put off doing it again.

Judging by the great number of people who turned up and stayed for the session, it’s clear I’m not the only one who is struggling with these issues, adding more weight to my suspicion that pair programming is the hardest of all the XP practices to master.

I worked with Laura Plonka to devise and run the session. Laura is researching her PhD thesis on pair programming, using video footage to analyse pair programming sessions, then running a retrospective where the pair get to debrief and share their experiences of the session.

Despite the huge contribution from everyone present, at the end of the hour, I felt as though we had only started to scratch the surface of the problems we’d identified. It seems as though too many teams, even at organisations who are ostensibly keen to embrace ‘agile values’, suffer from some toxic cocktail on this menu of dysfunction:

  • an agile-zealous leadership which forces people into unwilling or poorly-chosen pairs
  • a culture that, at some level, values heroics over craftsmanship, such that programmers may feel a subtle or unconscious reluctance to chose to pair on a task unless it looks utterly daunting, and there could be no shame in being seen to ‘ask for help’.
  • a team that disagrees on the types of tasks that should be done as a pair
  • team members who are far enough along the autistic spectrum (as Joseph Pelrine and Ben Fuchs pointed out, we have a higher proportion of these than many other professions) that they find the level of inter-personal communication required for pairing difficult or impossible.
  • ‘Experts’ on the team who feel that pairing with less experienced members of the team will slow them down too much
  • ‘Newbies’ on the team who are afraid to ask for help, or feel the work they’re doing is too mundane to need to be done in a pair

There were masses more issues brought up – these are just the main few that I can remember now. Hopefully more people will write up their sections on the session’s page on the XP Day wiki, or maybe comment on this blog post.

I spent the latter half of the session in a small group discussion the influence management can have on the adoption and enjoyment of pair programming. Paul Field and I enumerated the benefits that teams who embrace pair programming and create a culture where it works, can enjoy:

  • Better system knowledge across the team (higher truck number)
  • Skills transfer between team members (free training)
  • Team bonding
  • More defects found & found earlier
  • Better solutions/designs
  • More fun (better staff retention & morale)
  • Better focus (less time wasted in email / facebook)

It’s worth holding onto this list, and thinking about it when experimenting with pair programming within your team. Not all these benefits will be immediately apparent, so it’s worth being patient and trying to figure out ways to measure them to give you feedback as to the success of your experiment.

Another great idea I heard for teams that want to try pairing but are unsure as to which tasks are appropriate: try doing every task in a pair for at least five minutes. If, after that time you both agree that it’s a waste of time to do it as a pair, you can split up.

I still feel like there’s huge amount of work to be done to collect and disseminate the patterns and anti-patterns around pair programming, but I’m glad to have at least stirred up the pot a little. Thanks to everyone who turned up and contributed so much, and thanks especially to Joseph and Ben for organising a follow-up session later in the day where we had the opportunity to drill down into those psychological barriers a little bit more. Great stuff.

Agile / Lean Software Development

Comments (6)