More Trucks

The higher the truck number of your team, the more resilient it is to losing people. Pair programming spreads knowledge of the code around the whole team meaning each team member has a much more broad knowledge of the system than on a traditional team.

Free Training

Every time I pair with someone, I learn at least one new trick, be it a keyboard shortcut for my editor, a new command-prompt command, or a language idiom. This training costs nothing and builds the confidence of even the most junior team members who always have something to contribute, to say nothing of how much they will learn from sessions with their more senior colleagues.

Team Bonding

Working together in pairs breaks down barriers between people much more quickly than when they are working alone, and provides a natural environment for teams to learn to trust one another, and enjoy one another’s company. These are vital attributes that will get your team though the tough times, ensuring they can pull together when necessary.

Better Designs

Experienced programmers know that coding is much more a process of design than of mere implementation. When subjective design decisions are taken by at least two people on the team, those decisions have much more authority and are more likely to be understood and accepted by the rest of the team than if they had been taken alone. When one member of the pair has a good idea for a solution to a problem, this may stimulate an even better one from their pair. Science says so.

Less Bugs

The perpetual code review that’s done during a pairing session not only produces better designs, but it also catches a lot more defects as they are written. Pairs will tend to write more thorough automated tests, and are more likely to spot holes in logic that would otherwise have to be picked up by subsequent manual testing.

More Fun

Generally, programming in pairs makes for more a more relaxed and enjoyable atmosphere in a team. People become comfortable with their own strengths and weaknesses and are able to talk and joke about their work much more readily, since they are already used to that dialogue. This is obviously terrific for morale and staff retention.

More Focus

Pair programmers do not check their emails when they’re waiting for a script to run, disappear into their inbox for 20 minutes, then come back and have to remind themselves what on earth they were doing. When they hit a little break-point, they review what they’ve done so far and make a plan for their next steps. They stay focussed. Twitter can wait.

Mind if I run a couple of things past you?

I’m going to use personas in the session as a tool to help people discuss the anti-patterns that I think cause teams to struggle with pair programming. You’ll hopefully recognise yourself or people you’ve worked with in the past in these personas. What do you think? Have I missed any? Are they too obvious?

Goran, Architect

“For most tasks, pair programming just slows me down. When you pair with me, it’s not pair programming, it’s mentoring”

Goran has been programming professionally for over 15 years and draws on that experience to write clean expressive code. He can code fluently in C++, C#, Python and is handy in numerous other languages. He knows all the common design patterns and when to apply them, as well as numerous refactoring strategies.

Goran has tried pairing a few times, but doesn’t really see the benefit. He feels that his level of experience makes for rather uneven and therefore pointless pairing sessions.

Bart, Obsessive

“I just hate having to share the keyboard”

Bart is really gifted programmer who gets a huge amount done with few mistakes, but his team-mates often find it hard to understand and change his code. He’ll often use jokey or sarcastic names for variables and methods and has a tendency to write long, complex, methods. Bart drinks a lot of coffee and works long hours, often getting quite obsessed about finishing a particular piece of work.

Bart doesn’t really like the idea of pair programming. Although he understands the benefit of ‘no code ownership’ in theory, in practice he feels quite possessive about his code, and finds himself quickly becoming aggressive when discussing design decisions with other members the team. He often seems to upset his team-mates when he just thinks he’s being honest with them.

Moira, Anxious Project Manager

“My team doesn’t have time to work in pairs, we have too many bugs to fix”

Moira used to be a programmer back in the day, working on COBOL mainframe systems, so she knows the ropes. As everyone sticks to the plan, she sees no reason why things should go wrong. Right now her team are in the ‘testing phase’ of another project, and as usual there’s a frenzy of activity as bugs are uncovered by the testers and passed to the developers to be fixed.

Moira just can’t see how halving the number of bugs being worked on by adopting pair programming can help her team meet their deadline. To her, pair programming just seems like a fad that helps programmers have a better time at work.

John, Contractor

“I’m scared people will realise I don’t know what I’m doing half the time”

John is a contractor, a hired gun. He’s paid at least twice as much as most of his team-mates who are salaried. He’s experienced and highly competent, but secretly frets that he isn’t really worth the extortionate daily rate that he’s paid, and feels guilty when he gets stuck or has to ask his team-mates for help.

John has never tried pair programming but he worries how his team-mates will feel when they realise he sometimes needs to spend 20 minutes reading around blog posts and mailing list archives, or writing throw-away code to figure out how to use a library he’s never used before. Won’t they end up resenting him for wasting time?

Sarah, Wallflower

“I’m just used to programming on my own”

Sarah has been programming since her early teens and got top grades studying Artificial Intelligence at University. Sarah is naturally shy, and has always found comfort in programming as a place where she can express herself and her ideas without having to talk to people face-to-face, which she finds awkward and embarrassing. She contributes to a couple of open-source libraries and can often be found on IRC channels and mailing lists supporting the users of those libraries with friendly and eloquent responses.

For Sarah, programming has always been a solitary activity. She finds the idea of pair programming strange and quite intimidating, since she doesn’t think she’s very good with people.

Gary, Once Bitten

“Pair Programming is a load of old bollocks”

Gary has worked on a project before where the team claimed to be ‘agile’. They used Scrum and user-stories for planning their work, and the scrum-master encouraged them to use pair programming. In fact, the scrum-master forced the team to work in pairs, by picking pairs at the start of each 2-week iteration, and making sure the developers stuck to those pairs for the entire duration of the iteration.

By the end of each iteration, most of the pairs were so sick of working with each other that they would barely speak for several days afterwards. Gary found he would come in earlier and earlier so that he could get some time hacking on ideas he’d had but didn’t have the chance to play with during the main working day. He found pairing to be a drudge and a chore.

Rod, Whacky Races

“Every time I pair with someone new, I have to learn their bloody keyboard shortcuts”

Rod has just joined a new team who are using UNIX text editors to do their development in Perl. Rod is used to using the Eclipse IDE and has never really used these text editors before so he feels awkward and clumsy when he gets the keyboard. This is compounded by the fact that his team are using a mixture of editors and operating systems, with some people staunch EMACS users, others using VIM and yet more using Textmate on the Mac.

Rod likes the collaborative aspect of pairing, but feels hampered by the variety of development environments that his team uses. What can he do?

All thoughts and comments appreciated. If you’re in London tomorrow night, why not come along to the session and let us all know what you think?

If you’re on a team that’s using or trying to adopt pair programming, this is a great chance to explore and understand some of the complex reasons why this is such a difficult skill to master.

The session is free, so sign up soon to avoid disappointment:
http://skillsmatter.com/event/agile-scrum/debugging-pair-programming

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.

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.

Those of us who are lucky enough to have experienced working on a really effective XP team know about that almost magical thing that starts to happen when the barriers between different members of the team break down, egos and code ownership are cast aside, and the team starts to evolve the codebase as one, mighty, coding machine. It’s truly a joy to be a part of, or even just to watch.

When I worked at the BBC, we tried various experiments with different styles of pairing and retrospected on them regularly to figure out what was working. We went from the extreme of the same pair working together right through a whole story, sometimes staying together for a whole iteration, to switching up pairs several times a day. In the end, of course, we found a sweet spot somewhere in the middle, and seemed to know intuitively when a pair was going stale and needed a fresh injection of energy by changing up the members.

Compare this ideal with this description of “Total Football” (that’s ‘Soccer’ for those of you speak US English!)

“Total Football” is the label for an influential theory of tactical association football in which any player can take over the role of any other player in the team. It was pioneered by Dutch football club Ajax Amsterdam.
In Total Football, a player who moves out of his position is replaced by another from his team, thus retaining the team’s intended organizational structure. In this fluid system, no player > is fixed in his nominal role; anyone can be successively an attacker, a midfielder and a defender.

Regularly rotated pairs of programmers are essential in developing this kind of fluid self-organisation within a development team. While specialisation may become important for larger teams, there’s no doubt that keeping the whole team familiar with the whole codebase for as long as possible brings huge benefits.

For me, the biggest, and often the least mentioned of these benefits is that the team develops a kind of shared consciousness about the code and how they conventionally like to work with it. Not only does this mean the team can move extremely quickly, knowing exactly where to find something and how best to hack on it, but it is a stake through duplication’s dark and twisted heart: “Didn’t we work on something a bit like this last week, Brett?”. Once a team starts to think and communicate together this effectively, code re-use goes through the roof as common problems are solved in consistent ways, patterns emerge and are factored out for re-use.

You can probably tell, I’m a massive fan of pair programming, mainly because I absolutely love being this effective in my day-to-day work. How about you, loyal reader? What are your experiences with pair programming? Have you tried it? How was it for you?