Try everything once...

This post has been bothering me for some time.

I was tempted to point out that programming simply isn't like walking down the street. Programming isn't a straight race. In programming: fast!=good. But then, when I thought about it some more I realised that programming in a team is in some ways like walking down a busy street: like it or not, the best way for anybody to make progress is to have some sensitivity for the speed at which others are moving. In both programming, and in walking down the street: fast!=good.

Finally I wondered who would want to hire, or be on a team with, the kind of person who can't even walk down the street without getting annoyed. But maybe behind all this maladroit bluster is fear. This is what Kent Beck has to say about fear in the preface to his book "Test Driven Development".

• Fear makes you tentative [and so reluctant to try something new - like pair programming?]
  


• Fear makes you want to communicate less [like maybe not wanting to pair program?]


• Fear makes you shy away from feedback [like maybe not wanting to pair program?]


• Fear makes you grumpy [like getting annoyed with people you don't know for walking down the street?]

But what are his fears? Are any of them legitimate? It might be legitimate to fear that pair programming will mean that you will have to spend your entire working day explaining to some newbie where to put the semi-colons. For this reasons pairs should be changed regularly. It might also be a legitimate fear that some of our best ideas and our best problems to solutions happen when we're alone. A way of working that allows people to cook up ideas in private before they test them out in public is well-known in other collaborative fields - the so-called "Cave and Commons" approach. For that reason, pairing shouldn't be scheduled to take up the whole day. Programmers should be give time in their "Caves" to get their heads together and sketch out ideas. A friend of mine who regularly paired with someone and didn't take this approach said that he and his partner found themselves coming in earlier and earlier each morning to try to sketch out their ideas and find a solution to the previous day's problems before their partner arrived.

Pair programming is about learning from other people and letting people learn from you. Pair programming is about sharing the knowledge of a system around a team. If you're really worried that you're not going to learn anything new when you pair with someone, don't be. Ask any teacher, they'll tell you that you only really understand something once you've taught it to someone else. And that's assuming that you manage to find someone who really can't teach you anything. Chances are they will know something you don't know. They'll know a library you don't know of, they'll have worked on a bit of the system that you don't know. They'll know a keyboard short-cut in Eclipse, or (may a higher power preserve us) in vi. They'll have been taught the latest template libraries in their final year at college.

There are lots of reasons why this is a good idea. If a member of the team leaves for some reason, it reduces the chances that some part of the system will become impossible to maintain . It increases the chance that mistakes and problems that require knowledge of the whole system will be spotted. But it's certain that pair programming won't work if it's forced on people.


Agile Lab's Technical Aspects of Agile course offers developers a chance to experience pair programming in a safe, non-threatening environment. At the same time they improve their technical skills in test-driven development and their coding and architectural skills through refactoring.