Posted by Iwein Fuld mid-afternoon: August 17th, 2010
In the current market it becomes more and more likely that developers in the same team will not be in the same physical location. This is caused by outsourcing, but also other reasons like ever increasing focus on open source projects.
In a distributed scenario pair programming has huge benefits over meetings and sending comments on issues around. It is (still) the fastest way of sharing detailed information between people, and it actually gets the job done where a meeting does not.
The added benefit of pair programming in a distributed team is that it bridges the gap between the local team and the remote team that is caused by the fact that informal communication is impeded. Research has shown that pair programming works in distributed teams [1]. The challenge is to find out how to make it work for you.
In my previous blog on Pair Programming I focussed on the different styles that I see in my daily practice and ways of improving the dynamics in a pair. This applies equally to colocated pair programming and distributed pair programming. At my current client I bumped into the issues particular to distributed pairing, so in this blog I will outline habitual and technical prerequisites for successful distributed pair programming.
(more…)
Posted by Iwein Fuld in the early evening: May 9th, 2010
Without exception in all teams I’ve developed software in people have expressed their aversion against pair programming. It’s not that developers don’t want to try, or that they don’t believe it will help. On the contrary, they are usually very enthusiastic about trying it and give it more than a fair chance. After a few days they sit alone behind their keyboard coding like zombies with headphones. What’s going on? Is pair programming too hard? Doesn’t it pay off? In this post I’ll try to explain what I think is happening, and I will give you some clear pointers to avoid the traps. At the end I will go into distributed teams and what part of the game changes there.
So what are people saying when they have stopped pair programming and you ask them why:
- I’m faster on my own
- Can’t pair with that guy, he’s getting on my nerves
- Pair programming is too tiring
- We’ve split up the work and we’ll get it done faster if we use two keyboards
- There’s too much background noise
- I’m just slowing her down
Some of this might sound plausible, so let me axe that down first. No you’re not faster on your own, you’re just creating more crap for your colleagues to puzzle over and eventually delete. The code you write alone sucks. That guy that is getting on your nerves is trying to tell you (clumsily) that your code sucks, try to listen to him and you’ll turn into a better programmer. Or maybe you can teach him something and he’ll stop getting on your nerves. If your code is so simple that you can split up the work in advance you’re writing it on too low an abstraction level, or you need to work on this in two pairs. If you’re slowing the other guy down, that’s a good thing. That will prevent him from writing code that you cannot maintain. If you don’t feel worthy of your colleagues code, get over it, or get off the team.
(more…)