Pair Programming is Kryptonite!
June 25, 2009 10:00 AM
Pair programming is easily the most controversial agile development practice and in my experience the most frequently avoided. It makes some people pretty uncomfortable.
Just so we're all on the same page, pair programming means two programmers working together on one computer. Yes really. Normally one codes while the other thinks ahead and around. Or, one drives and the other navigates, swapping regularly. The motivation is higher quality output from the outset.
Pair programming requires working much closer with team mates than most developers are accustomed to. This is both its power and it's greatest weakness.
Working so closely with others can bring otherwise hidden personal issues to the surface. My experience in previous jobs has shown me that pair programming can be so personally challenging for some people that the practice is infeasible for that team. Doing it takes courage and maturity, it requires a healthy environment where mutual respect, humour and humility are all expected. Not to mention minimum standards of personal hygiene! This is quite different from the stand-offish formalism characteristic of many alternatives and this humanistic style sets the bar too high for some. Cowboys, incompetent introverts, control freaks and superhero programmers all resist pair programming. It's like their kryptonite.
Like culture shocked westerners first visiting Tokyo, unused to the dramatic reduction in personal space one can expect, say, on a commuter train, for some, getting used to the personal invasion that is pair programming is a self-imposed barrier they just need to break through.
Pairing up with different people makes this personal contact a dynamic challenge. There are several axes of individual difference which demand different behaviour. For example there's the novice-expert axis and the introvert-extrovert axis and people have different natural working styles and favoured problem solving strategies. For example I can often be willing to explore unconventional solution paths which make methodical people a little unsettled. Being aware of that helps me communicate appropriately and change my behaviour where necessary.
Pairing requires bilateral adaptability and the art of compromise.
There are many common anti-patterns that lead to ineffective pair programming. These things are fairly well documented, for example see Pair Programming Illuminated by Laurie Williams and Robert Kessler. It's worth tackling these problems actively because ineffective pair programming is worse than no pair programming and it's obvious even to would-be starry-eyed XP fans.
One of the reasons I've been thinking a lot about pair programming recently is because I haven't been doing it for a change. (gasp!)
Apart from some time on support and fixing a pile of trivial bugs (not pairing), I've been working solo on a front-end feature for JIRA 4.0. Solo because our team has an odd number of people right now (wanna job?). It has actually put me in a great position to evaluate the practice of pair programming somewhat objectively.
First the good stuff about not pairing. I have some great new headphones and with the right music I can get into the zone and stay there for hours without needing to coordinate with anyone. I do not have to continually exert effort listening or thinking of ways to express my questions or ideas. I just think and do. That's refreshing.
But I'm not ashamed to admit it's a little isolating. Hey, I'm a people person.
The negatives of not pair programming are especially visible when you are accustomed to doing it. While not pairing recently I have become curiously suspicious of the quality of my work.
I think it's good, Is it really good? I'm not gold-plating am I? Maybe this is absolutely the wrong approach. Is there something obvious that I'm missing? I'd better get someone to review this.
All those thoughts are plaguing me in my "step back moments" when the tests pass and I get to wonder about the next move. This wouldn't happen if I was pairing. I would be in dialogue with my partner; we would have common mind (just imagine Yoda saying that last bit).
Pair programming can really help in making a team gel. Spending time together - not just in pair programming but in other activities like sharing a meal or social event during work time help teams to gel.
So while there are many reasons to practice pair programming, it's not the only way to get these benefits. Code review is an obvious alternative for many of the same benefits. Marketing may want to break my arms if I don't mention Crucible at this point.
So if you're not improving the quality of your code with pair programming, then I'd hope you are doing code reviews because there really isn't much disagreement in the industry that this is a very well known and effective method of ensuring quality software development.
Atlassian development teams do either one or the other, or sometimes, like in JIRA some of both.
Using a tool like Crucible for code reviews has some advantages over pair programming, such as record-keeping and working across distributed teams and time zones. Pair programming has some advantages over code review such as swapping keyboard shortcuts and shell one-liners and helping a team to gel.
So if you have a business case for better quality software then remember: two heads are better than one!
Copyright © 2009 Atlassian Pty Ltd.
6 Comment(s)
For the super hero programmer, pair programming is a nuisance. If your partner is not on the same wavelength then it will just slow you down. Also, one has to take into account the cultural aspects. For example, I am most productive after midnight but before 3 am. I am not likely to find anyone else who can think effectively during those hours. During waking hours I hypothesize, analyze and design solutions. Also, I've known many other "super hero" types who cannot handle critiques in person, they need to let the critiques sink in for them to allow them to get past their egos for them to admit they are "wrong". This is why one has to get past the ego barrier and be very comfortable with your pair-mate. However; I like to think very far ahead and I think in a very system integrated manner, very few people think that way. So for us integrative thinkers, pair programming represents a rather backward approach. For us programming is just a formality not the majority of the work. Design is where we spend most of our creative energies. Perhaps, pair design is more our style. In fact, the abstract thinkers like me, are just as comfortable delegating our designs to pair programmers to implement as doing the detail work ourselves, unless it is a leading edge assignment where creativity goes hand in hand with implementation. I have yet to see any personal benefits from pair programming. I think my personal productivity would be adversely affected by such a work style. For some, I can see it as a real benefit, for others, as you say, not.
By nelson perez at August 14, 2009 7:32 AM
This was a great article and really summed up my thoughts on the topic. Ive written a little blog post after reading this: http://nerdgerl.wordpress.com/2009/10/03/pair-programming-a-few-thoughts/
By Georgi at October 3, 2009 3:39 PM
Chuckled when I read what's good about not pair programming:
"I have some great new headphones and with the right music I can get into the zone and stay there for hours without needing to coordinate with anyone." - Ahh so true!
We have had similar experiences with Pair programming. I would have to agree with you in saying that it helps the team "gel". We've also found it to be excellent in up-skilling people or making sure people are on the same page on a new bit of code or a new system.
We still use Crucible for our code reviews, however we have found that not everyone (a) has time to do code reviews or (b) can't go through all of the code in great detail. We also use the code review aspect for training, and have found it to be a good way to show other developers new features of an app or a new technique you've picked up to do some specific task.
For us, a mix of the two seems to be working well. Like Charles says in the video, having a partner to code with is great to ensure that someone else has gone through your code in detail. Doing the code review makes sure the rest of the team is across whats going on in your code.
Sherif
By Sherif Mansour at October 3, 2009 5:02 PM
Pair programming is only useful for certain devs:
junior + junior = faster for both
junior + senior = faster for junior, slower for senior
senior + senior = slower for both
By Anonymous at October 29, 2009 5:32 AM
Anonymous,
Perhaps it depends on what you're working on? There are plenty of difficult problems out there.
Development speed is not the only metric that determines what is "useful" or measures business value. Quality can also be valuable.
At Atlassian if we ship a new version of a product sooner but it has (more) bugs in it, that will result in a significant expense in supporting the product. Not to mention the loss of confidence that our customers might have in our products. Then we have to go back and fix the bugs, so if we add that time to the original time spent we may discover that it wasn't faster in the end. Often this additional time is not attributed to the original feature work and the true cost is never measured.
If only it was as simple as you suggest.
By Chris Mountford
at
October 29, 2009 4:24 PM
Perhaps looser group programming IS beneficial, though, right? I see from photos of the Atlassian environment that there tends not to be walls so programmers can communicate with each other and work together as needed. This seems to work very well for open-lab teams I have worked with. But when it comes to working on something new and "out there", adding another body or brain to the mix just slows me down. But I guess what I am talking about is just good ole peer reviews and not pair-programming. But perhaps it qualifies as limited pair programming, just on weak aspects of the code that could benefit from a more senior person's insights. But I prefer feedback versus someone babysitting me through the darn change. I don't need no stinking softare babysitter.
By Nelson Perez at November 2, 2009 3:04 AM