It might seem strange but I still work at ThoughtWorks!

I hear what you say. I’ve come across a lot of people that fall back on to default stances when it comes to programming practices. Some of these practices may not suit the environment or the team in which they are used. I prefer to analyse the battlefield before executing a strategy than to march directly into the line of fire. Teams need to work out whether pair programming is right for them.

I don’t like the opinion that you have to pair program because it will improve knowledge sharing or quality of code.

There are many open source software that we depend on where there isn’t a lot of pair programming going on, but we use them nonetheless, even in mission critical applications. So there are obviously other facets to software development that can contribute to knowledge sharing and quality. But at the end of the day it just comes down to good communication amongst the team.

Cheers,
Nick.

Out of the top 10 people I wouldn’t enjoy pair programming with (for the reasons you mentioned in your post), 8 of them were Thoughtworkers.

I think pair programming is valuable to introduce someone new to the project, or when there’s a complex problem to solve. Other than that, I’m not convinced.

It’s funny how TW evangelize pair programming as if it’s from the bible. I can’t wait the day when something else come along, then TW would revolutionize IT again and (learning from history) they will bash pair programming as if they never did it before :p.

Anyway, great balanced post. And you’re a great balanced person. Take care.

Personally, I love pairing, and I find a lot of people who hate it are doing it in ways that I hate, too. I agree that mutual respect is absolutely required. However, I think that’s also required for any sort of teamwork; if teammates don’t have mutual respect, I’d be worried that separating them would just store up trouble for later, rather than making it go away.

Still, I agree that there are some people who will probably never like pairing, and many companies where it doesn’t fit well in with the culture. For them, I agree good peer reviews are a must. I’d guess that maybe one team in five is doing either pairing or peer reviews well, so it seems like there’s plenty of room for both practices to grow.

I’ve had better experiences with peer reviews, but that is from my own personal experience. Sure you can argue that if the people involved in a peer review don’t do a good job then you end up with poor quality code, but the same goes with pair programming. Your pair could easily become disengaged and you end up doing all the work.

I would prefer a lighter weight process which involves peer reviews (or technical retrospectives), and pair programming when you need to face a complex task. I don’t believe in needing to pair to gain a shared understanding of the code base, because if you work in an Agile way you will end up working on different areas of the code base depending on which story card you pick up next.

As mentioned in the journal paper above, pair programming takes longer to deliver, and the benefits of pairing are minimal. I’ve experienced this on projects which is why the research struck a chord with me.

I want to deliver high quality software quickly, and I believe there has to be a better way to achieve this. Pair programming in my mind is not the silver bullet. Knowing when and when not to pair is a hard team dynamic to master. But I’m sure if you can get a good balance then I’m sure you can still produce high quality code at a higher velocity.

At the end of the day it does come down to good communication amongst the team. As you said it is all about the people, not the process.

With the same arrogant people you mentioned doing the peer review I doubt it is going to be that much greater for the team compared to pairing.
i.e. it all comes back to the peopl,e not the process