Pair programming is not for me
I hate pair-programming (shock and horror), especially if I have to share a keyboard with arrogant and obnoxious people. Pair-programming requires a lot of mutual respect between both developers. If there is no respect then pair-programming won’t work, and you will have a lot of disgruntled workers. It hinders creativity and expressiveness all for the sake of your pair going on an ego trip.
I see the value of pair-programming, especially when you need to drive out something that is overly complex, or when starting a new project for shared understanding. Being pragmatic, I just don’t see it as something that should be done all the time.
There is even empirical evidence that does not support “the hypothesis that pair programming in general reduces the time required to solve the tasks correctly or increases the proportion of correct solutions” [1].
My colleagues will frown on this but I can’t wait for the day when pair-programming goes out of fashion again, and peer-reviews or something else becomes “fashionable” again.
[1] E. Arisholm, H. E. Gallis, T. Dybå, and D. I. K. Sjøberg. Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise. IEEE Transactions on Software Engineering 33(2):65-86, 2007.
I would rather neither is done because it is “fashionable” but just hope each team (or even finer level, individuals on each team) chooses what works best for the them/team and/or work out how to improve the which ever process that believe works. Since honestly I don’t think this is a one or the other thing and I’ve seen peer reviewed done poorly yielding the same negative result you mentioned, or just the reviewer wasn’t doing it properly.
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
Andy Shen
4 Jan 09 at 3:24 pm
Hey Andy, how is it going? I seem to follow you around from company to company these days.
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.
Nick
4 Jan 09 at 10:04 pm
Not bad thanks. Yeh there’s only so many places in CBD eh
Andy Shen
5 Jan 09 at 5:43 am
Hi, Nick!
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.
William Pietri
7 Jan 09 at 12:13 pm
You’re probably the most down-to-earth ex thoughtworker I’ve ever known
.
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.
Elmira
15 Jan 09 at 11:40 pm
Hi Elmira,
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.
Nick
16 Jan 09 at 8:17 am
Hi Nick,
I have to agree with some of the comments made about this post. I really don’t like pair programming. I think it’s useful for complex tasks or getting new team members on the same page, or for teaching TDD but having to pair with someone everyday all day was a complete drag for me.
Georgi
2 Apr 09 at 4:44 pm