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

Estimate: an approximate calculation of quantity or degree or worth

Commitment: the act of binding yourself (intellectually or emotionally) to a course of action

• Estimates are not commitments.
• Plans based only on estimates are bad plans.
• Commitments based only on estimates are at best foolish, at worst dishonest.

Estimates are certainly a useful tool for making realistic commitments, but there are many others too that are equally, if not more, useful. Working at a sustainable pace, measuring data about past performance, and facilitating the genuine consensus of the whole team when committing are the way to make plans that can actually be achieved.

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.

I rather dislike this tendency to put people into boxes, as the next obvious step is to write the person off, but I guess giving these stereotypes a name at least gives you a framework for discussing them and starting to figure out what is driving their dysfunctional behaviour.

Plus we can all recognise a little bit of them in ourselves, and our fellow team-mates. Anyone else lucky enough to have a bit of an EXTRA TERRESTRIAL on their team? (Hi Brett!)