- Posted by dan on February 18, 2011
Of all the XP practices the one that has the most resistance is pair programming. Two developers sharing 1 computer, sounds like you're wasting money doesn't it! We've been "Pairing" for quite a while, and I thought share some of my observations and experiences.
Some love it some hate it
The Chatty Coder
As with everything, some people love discussing the problems they face. They tend to be the vocal one's that might discuss whilst waiting for their tea to brew whether this bit of logic should be in the model or extracted out into a helper class.
What do you think? Does this belong in the domain or not? Is this class doing do much?
Naturally this person enjoys pair programming and feels the benefits, because they feel both devs are learning and becoming better through the pairing. The morale boost alone from this is worth the exercise, you'll find more talking but also people accidently working through lunch because they're so engrossed in what they're up to.
The Headphone Hero
Other's are more solitary, they prefer working with their headphones on in their own world away from all the distractions of the office around them. They ask no questions and strive to get to coding nirvana. They aren't such big fans of pair programming. They do it without complaint, but in the pub would question the logic of having someone sit their and watch them code. What sometime's seems to work is put them with someone a bit more junior and they think
of it more as a teaching exercise and are therefore more willing to communicate. Though they tend to control they keyboard until they realise their partners been watching them for 30mins. At this point they'll thrust the keyboard to their partner in a "there you go boy" kinda of manor. You can perceive this as patronising but over time even the hero's realise their partner can give them a few pointers to help them on their way to code nirvana.
The Argumentative A**hole
For some, every action taken by others is up for debate and has to be wrong. These people claim to enjoy pair programming, but only really so they can point out the mistakes of others. They can be disruptive to a team and are often the person people dread pairing with. Time's a great healer and over time these people aren't so argumentative because they become to understand the ways other people look at it. They may often be proved wrong on numerous occassions.
Pair Programming Techniques
Ping pong pair programming
Where one dev writes a failing test, the other makes it pass, then they write another failing test, back and forth back and forth. This is the one most people have heard of. It works well, it's almost like a game; where you're to an trying to break the other devs code, or pass the test by doing the minimum amount of code.
I find it a good starting point where you say, "Well if I add 2 and 2 I should get 4". The other dev hardcodes 4 as the return value and it all spirals from there.
Fusing Pair and Solo Development
Where you pair on a more adhoc basis mainly under the guise of "knowledge sharing" of a more experienced dev with a less experienced. I think this technique is characterised by the headphone hero above. Some people don't buy into the benefits of pair programming, but tell them it's for skill transfer and they'll accept it. Then over time they'll even enjoy it. Though they still may always have a bias towards their headphones.
Remote Pair Programming
This is the one I haven't done. I'm lucky enough to be in a team where all the devs are literally sat around me. I've heard of people doing this with Skype though. I listen to the TechZing podcast and one of the presenters Jason Roberts has mentioned how he pairs on his startup AppIgnite with a partner in Norway I think. Anyway I'm sure I'll give it a shot at somepoint.
A Tale of 2 Keyboards, mice, monitors and developers
We've gotten to the point now where we have essentially 2 dev pairs in our team.
Each pair have 2 keyboards and mice. Two monitors of-course is standard even for 1 dev. Sometime's there's a bit of mouse wars over who's controlling the mouse but on the whole it works well.
One dev might be ready with the compile and test shortcut the second the other dev has put the ; at the end of a line. It also seems to reduce the "would it be better if we renamed this to" talk, rather they ask the question prehaps be given the keyboard for control, you can demonstrate it instantly. Just be careful what your partners up to with the mouse. You almost end up learning more ReSharper shortcuts out of necesessity because the mouse can dangerous with people moving the cursor all over the show.
2 keyboard and mice is really what I consider extreme pair programming and yes I sometimes wish there were 2 cursors and mouse pointers on screen, the day visual studio allows multiple people editing like Google docs will be an interesting one... hmm seems like a startup idea there.
Rotating the pairs
One thing that's sometime's hard to do is rotate the pairs. I think we just quickly get into habbits of working with the same people. But it's important to rotate the pairs to keep everyone up to speed on what's going on within the team. We've tended to have 1 pair working on 1 story for its duration, but when thinking about it. We'd probably benefit from regular swapping. Just to avoid the "Bills ill today" you're on your own and you lose the ability to confer with anyone on the problems. Whereas if everyone was somewhat familiar with the story it's not so much of a problem.
Whether it's best to rotate round once a day, or every few hours I'm not sure on. I think we all want to finish what we've started. I hate being torn away from a failing test, or some problem that's consuming your thoughts. I leave it to your discretion see how it goes. But aim for all devs knowing about the inner workings of all stories.