Wednesday, 29 August 2012

A Case For Pair Programming - The Follow Up

A few days ago I presented a case for pair programming. Around the same time Gus Power forwarded Paul Graham's insightful article on the Maker's Schedule to the Energized Work mailing list. In response Kris Lander made the following statement...
This just adds to my growing belief that there are a lot of things we could do to improve the way we work both individually and as a team and that we might have to take a second look at a number of things we've been quite evangelical about. Pair Programming is one that I'm really starting to change my view on for example.
My ears pricked up. EW crew members are some of the best around, so when one of them makes a statement that appears to challenge my beliefs it's worth finding out more. I asked Kris to expand. He went on to explain while he valued pair programming, he thought it could be wasteful in some situations. He also suggested that when working alone, one may learn more effectively through trial and error than when working in a pair. It's well understood within Lean Software Development that it is not the fastest or biggest organisation that survives, but the one that adapts most quickly, hence great value should be place on learning, and this could potentially outweigh the benefits of full time pair programming. Furthermore learning (or mastery) is one of the key ingredients of intrinsic motivation, whereas working with someone always one step ahead of you can be demoralising. Finally Kris said he found that working in a full time pairing environment can lead to stagnation, since there is less opportunity to experiment. When working alone, you might permit yourself to briefly investigate something that catches your interest, even if it is not directly relevant to your story. Working in a pair this is less likely, and not everyone will have the time or desire to do this outside of office hours.

The discussion went on for days, with other Energized Workers supporting Kris' view. Simon Baker reminded us of what Kent Beck wrote in is original book on XP. I'm ashamed to say I don't have a copy to hand, but Simon summarised things nicely by saying...
He strongly advocates personal time for people to cut code, explore ideas, spike, make a mess, learn. Then to bring their ideas and discoveries back to the pair and cut the production code. This way people get a chance to at least have a crack at something once, then to do it again in a pair boosted by what they've tried previously, eliminated and learnt.
Kev Richards added that he's always found it hard to let other team members struggle over something, trying to get to grips with it and understand it. But the struggle is necessary - no pain no gain! By helping them understand, frequently he's getting in the way. However he also warned that the results of not pairing could be a nightmare.

Odette Power was reminded of a recent engagement where she learnt more in one day's pairing than in the first four weeks, but also said she often prefers to thrash a problem out on her own in order to really understand it.
In short, I think I'm with Simon (as Kent said) - pairing at the right time, and in a ready state of mind (fresh, new problem domain) is amazing. But not all the time. We know the what and the how- but let us not forget the WHY.
Tom Dunstan paid tribute to the benefits of pairing, but also believes that learning can be most effective when done alone...
Levelling up has to be personal trial and error. Even doing something badly and having someone point out a better way is still better than never having done it yourself.
Chris Pitts joined the party late,  but also agreed that pair programming should not be a full time activity...
When it works, it works beyond my wildest dreams, but it is fragile. Like a lot of agile techniques, it falls apart quickly if the wrong attitudes are present. The usual rules of honesty, humility, respect, and more than a bit of thick skin need to apply at all times. As always, the main problems are usually in the wetware. 
There does need to be downtime. Certainly I personally find it incredibly difficult to pair 100% of the time when there is uncertainty and doubt about the right route forward. When neither pair is familiar with a domain, or cannot see a solution to work towards (or cannot explain their logic!), I think that I can often learn much faster on my own; I can experiment faster, and rapidly try different solutions until I see something that is promising. Then I prefer to bring it back into the pair for validation and sanity checking.
Chris also expressed concern that pair programming (and Agile software development in general) requires a set of social skills that are not traditionally present in software developers.

Rob Fletcher backed up Chris' view that pairing is fragile and more suited to some tasks than others...
I've experienced it being incredibly productive and at other times felt like my pair or I (even both) are not involved. I'm not sure why it sometimes doesn't work. Sometimes it's the nature of the task, sometimes a personality clash, wrong mix of skills or abilities or just someone not in the right frame of mind. Even then I don't necessarily think pairing is _less_ productive than if those people were working individually. 
it's more suited to some tasks than others. I do a fair bit of coding in my spare time & find that I enjoy going solo when doing exploratory "spiky" stuff but find myself wishing for a pair when building code out from the results of such spikes. I miss the validation that I'm on the right track, the pressure to stay focused.
The discussion is still ongoing, but has made me realise that while presenting the benefits of pair programming, I had completely neglected to point out its problems or indicate in what situations it might not be appropriate. It's widely accepted that different people prefer different learning styles (but contested that teaching in the learning style preferred by the student is more effective). My preference is for learning by example, but I don't mind whether this example comes from a colleague, formal documentation, a blog post or my own trial and error. I wonder whether people with other learning styles find pairing more stressful and tiring than I do? It's worth considering.

I also agree that when spiking (the process of investigating one or more possible solutions to a design problem) can be more effective when pairs split up and work individually. I sympathise with Kris' point regarding stagnation. With two young kids, a long commute and a serious attempt to get fit before I hit 40, I'm finding it harder and harder to dedicate the time I would like to technology. Maybe this is another reason why organisations should adopt some variation of 20% time. If they did they might even end up inventing something as profitable as the post-it note. But that's another blog post.

Many thanks to the EW crew for drawing attention to pair programming's downsides and helping me level-up my thinking.

No comments:

Post a Comment