I'm glad that this article includes the downsides of pair programming. Not that I think pair programming is bad, I'm just old enough now to know that there is no one "true" way to program as every situation and person is different.
My group switched to it for about 6 months and then aborted it and went back to a code review work flow.
For us the downsides of pair programming were:
- slowed down the velocity of the team. Alot fewer new features got implemented, with no perceivable gain in code quality, and as the person who lead the pair programming band wagon, I tried my best to show pair programming lead to better code. But in our case it didn't give us better code by any quantitative metric.
- frustration for senior people when paired with juniors, ie too much sitting around and explaining instead of actual implementation. We found it better to let new people page in knowledge as needed on their own speed rather than making senior people wait while junior programmers got up to speed
To be honest we found the best bang for the buck was to have teams of 3-4 people who are working on a subsystem sit together in a big room, they'll do a very informal form of pairing when needed, which can happen for a couple of hours a day and then they'll go back to working on their own when they need to.
I think the biggest tell about how effective pair programming can be in the long run, is that it was introduced around 2000 with the extreme programming movement. In the past 15 years, how many software companies can you name that mandate pair programming for a period of say 3 or more years.
I'm sure there are some, but if the most successful companies don't mandate it then its worth examining why it isn't mandated.
Perhaps pair programming's sweet spot is the last month before a big software release, where quality is paramount, communication is even more important and the team is in full on polish and bug fixing mode?
"To be honest we found the best bang for the buck was to have teams of 3-4 people who are working on a subsystem sit together in a big room"
This. In my previous job the 5 person team of I was part of quietly took over an unused meeting room and had the most productive 3-4 week span that any of us had encountered in years. Part of it may have been that no one could find us, which caused people to complain and our manager finally forced us back to where we supposed to be. Productivity dropped instantly, but at least people could bother us with trivial, non-breaking IE7 bugs.
Comments
I'm glad that this article includes the downsides of pair programming. Not that I think pair programming is bad, I'm just old enough now to know that there is no one "true" way to program as every situation and person is different.
My group switched to it for about 6 months and then aborted it and went back to a code review work flow.
For us the downsides of pair programming were:
- slowed down the velocity of the team. Alot fewer new features got implemented, with no perceivable gain in code quality, and as the person who lead the pair programming band wagon, I tried my best to show pair programming lead to better code. But in our case it didn't give us better code by any quantitative metric.
- frustration for senior people when paired with juniors, ie too much sitting around and explaining instead of actual implementation. We found it better to let new people page in knowledge as needed on their own speed rather than making senior people wait while junior programmers got up to speed
To be honest we found the best bang for the buck was to have teams of 3-4 people who are working on a subsystem sit together in a big room, they'll do a very informal form of pairing when needed, which can happen for a couple of hours a day and then they'll go back to working on their own when they need to.
I think the biggest tell about how effective pair programming can be in the long run, is that it was introduced around 2000 with the extreme programming movement. In the past 15 years, how many software companies can you name that mandate pair programming for a period of say 3 or more years.
I'm sure there are some, but if the most successful companies don't mandate it then its worth examining why it isn't mandated.
Perhaps pair programming's sweet spot is the last month before a big software release, where quality is paramount, communication is even more important and the team is in full on polish and bug fixing mode?
This. In my previous job the 5 person team of I was part of quietly took over an unused meeting room and had the most productive 3-4 week span that any of us had encountered in years. Part of it may have been that no one could find us, which caused people to complain and our manager finally forced us back to where we supposed to be. Productivity dropped instantly, but at least people could bother us with trivial, non-breaking IE7 bugs.