100% pairing might sound good in the short-term, but you're going to fry your developers. You'll also limit the productivity of your developers, who may be inclined to take more risks when working solo than when working as a team.
By eliminating code reviews, you've also limited the audience for some of the new discoveries, successes, and failures that developers will make.
I remember vividly the push for 100% pairing in 2000. It's a great idea for the short-term on well-defined, low-risk projects, but for anything spanning a longer period of time, it's a productivity-limitiing strategy that can burn out your devs, especially the more introverted ones.
All things in moderation, including pairing and code reviews.
This. There are so many things that having a pair will just serve to inhibit (exploratory development/research, etc), and some things that just don't need it (simple tasks, automation projects, etc.)
I love pair programming when working on something tricky, especially if I'm working with someone who knows a lot about the domain, but I really think that 100% is overkill - the parent commenter mentioned burnout, and I think that's right on the mark. Reserve pair programming for a specific project or task, especially one that's especially tricky, mission critical (security, reliability), or difficult in some way. Let developers work solo on everything else.
Maybe having a formal "ask-for-a-pair" policy would be a good compromise. If everyone is expected to participate regularly in pair programming when someone else wants backup, you can reap many of the benefits of paired work without driving your devs crazy :)
One more thing- pairing is an active process, in the moment, while code review is reflective. During coding, you are exercising a lot of "instinctive" skills, and in a pairing environment, you are pressured to act.
Code review happens after the fact, and gives the developer and the team a chance to reflect on what was done and to use deeper, slower skills.
I'm well aware that our Twitter-fueled society is trying to eliminate reflection as a practice, but thoughtful reflection is a tremendous source of learning and growth. Removing reflection from the coding process limits the growth capabilities of the team.
I don't agree with your assertion. Code reviews are not more "reflective" than pairing.
PRs, as implemented by nearly everyone, are a failure. The only way to review a PR is to check out the branch and look at the entire context of the patch, not just the diff. For that matter, it requires the reviewer to understand the code that is being changed. The reviewer needs to more or less independently solve the problem. It is possible to do this review after the fact, or while the code is being written - in either case, the same knowledge is required.
In practice, everywhere I've ever worked, "good enough" nearly always gets merged - slightly better methods don't tend to make it back into the PRs for a million reasons. These sorts of problems do get fixed with pairing.
Way back in 1998, I worked at the shipping dock of a distribution warehouse, on the 2nd shift. I was the only guy there most days.
My job was to stack all the boxes for a particular store on the pallet bound for that store. When the stack was tall enough, I wrapped the pallet in plastic and wrote the store number on the plastic.
At that point, there was a QA check to ensure that the number on the plastic matched the number on the boxes. Since I was the only guy in shipping during that shift, guess what happened?
Yes, you're right. I had to do the QA check on my own work, immediately after doing it, somewhere between 4 pm and midnight. The company is very lucky I only ever screwed that up once during the entire summer. That taught me a valuable lesson for the entire rest of my life:
Always separate the QA from the work in a meaningful way.
In pair programming, as long as one person is actively working, and the other verifying, that works tolerably well, but if those roles start to blur, you're asking for trouble. And the longer the pair works, the more likely that is to happen. The two pairs of eyeballs become less like a front view plus side view and more like a stereoscopic image from nearly the same angle.
You're also setting up a mutually assured snitching situation, where both people in the pair want to declare that they are both burned for the day and need a slack break, but neither can be the one to call it. If you're inclined to try pairing on your team, I'd recommend no more than three consecutive hours in a pair, followed by at least one hour of less intensive individual work. While I have been able to stay in hyperfocus for much longer than that individually, there's no way I could with another person in the room--probably not without the assistance of a research psychologist, anyway.
How mature is the product that the team is working on?
I think as a product (or core dependency) becomes more mature code reviews are immensely valuable. It also seems to become an issue when new members of the team are still getting their bearings. When a new member joins my team I generally book time explicitly for reviewing not only code but the development process that they follow. This helps suss out any issues they may have with environment, workflow , etc.
The product is mature enough to warrant all of those things, and when new members of the team are on-boarded, time is certainly carved out for code orientation. However, being forced to work on a story from beginning to end with a team member who knows how to pair well and knows the code base well is even more valuable in the end. Pairing is absolutely the best way to share knowledge, as it is necessary for the pair to be successful.
Comments
100% pairing might sound good in the short-term, but you're going to fry your developers. You'll also limit the productivity of your developers, who may be inclined to take more risks when working solo than when working as a team.
By eliminating code reviews, you've also limited the audience for some of the new discoveries, successes, and failures that developers will make.
I remember vividly the push for 100% pairing in 2000. It's a great idea for the short-term on well-defined, low-risk projects, but for anything spanning a longer period of time, it's a productivity-limitiing strategy that can burn out your devs, especially the more introverted ones.
All things in moderation, including pairing and code reviews.
This. There are so many things that having a pair will just serve to inhibit (exploratory development/research, etc), and some things that just don't need it (simple tasks, automation projects, etc.)
I love pair programming when working on something tricky, especially if I'm working with someone who knows a lot about the domain, but I really think that 100% is overkill - the parent commenter mentioned burnout, and I think that's right on the mark. Reserve pair programming for a specific project or task, especially one that's especially tricky, mission critical (security, reliability), or difficult in some way. Let developers work solo on everything else.
Maybe having a formal "ask-for-a-pair" policy would be a good compromise. If everyone is expected to participate regularly in pair programming when someone else wants backup, you can reap many of the benefits of paired work without driving your devs crazy :)
One more thing- pairing is an active process, in the moment, while code review is reflective. During coding, you are exercising a lot of "instinctive" skills, and in a pairing environment, you are pressured to act.
Code review happens after the fact, and gives the developer and the team a chance to reflect on what was done and to use deeper, slower skills.
I'm well aware that our Twitter-fueled society is trying to eliminate reflection as a practice, but thoughtful reflection is a tremendous source of learning and growth. Removing reflection from the coding process limits the growth capabilities of the team.
I don't agree with your assertion. Code reviews are not more "reflective" than pairing.
PRs, as implemented by nearly everyone, are a failure. The only way to review a PR is to check out the branch and look at the entire context of the patch, not just the diff. For that matter, it requires the reviewer to understand the code that is being changed. The reviewer needs to more or less independently solve the problem. It is possible to do this review after the fact, or while the code is being written - in either case, the same knowledge is required.
In practice, everywhere I've ever worked, "good enough" nearly always gets merged - slightly better methods don't tend to make it back into the PRs for a million reasons. These sorts of problems do get fixed with pairing.
I agree with the need for reflection, both in professional and personal settings.
However, you can see how in some places code review degenerates to a sort of rubber stamping process where little value is added.
This is about a team of 4 people, so pair programming is 50% of the team writing all code. I don't think there is a problem with visibility.
Whether this has many lessons for teams 10x the size is another matter of course.
A team 10x4 has all sorts of problems beyond pair programming.
Way back in 1998, I worked at the shipping dock of a distribution warehouse, on the 2nd shift. I was the only guy there most days.
My job was to stack all the boxes for a particular store on the pallet bound for that store. When the stack was tall enough, I wrapped the pallet in plastic and wrote the store number on the plastic.
At that point, there was a QA check to ensure that the number on the plastic matched the number on the boxes. Since I was the only guy in shipping during that shift, guess what happened?
Yes, you're right. I had to do the QA check on my own work, immediately after doing it, somewhere between 4 pm and midnight. The company is very lucky I only ever screwed that up once during the entire summer. That taught me a valuable lesson for the entire rest of my life:
Always separate the QA from the work in a meaningful way.
In pair programming, as long as one person is actively working, and the other verifying, that works tolerably well, but if those roles start to blur, you're asking for trouble. And the longer the pair works, the more likely that is to happen. The two pairs of eyeballs become less like a front view plus side view and more like a stereoscopic image from nearly the same angle.
You're also setting up a mutually assured snitching situation, where both people in the pair want to declare that they are both burned for the day and need a slack break, but neither can be the one to call it. If you're inclined to try pairing on your team, I'd recommend no more than three consecutive hours in a pair, followed by at least one hour of less intensive individual work. While I have been able to stay in hyperfocus for much longer than that individually, there's no way I could with another person in the room--probably not without the assistance of a research psychologist, anyway.
Good points in there. It might be that our personalities on our small team lend well to pairing and it might not scale out as we grow the team.
I would say though that it feels like we have even better visibility into new discoveries/successes/failures.
Every morning, we have a standard standup and afterwards we talk about anything anyone jotted down on the whiteboard from the previous day.
Today, it was huddling around some code for 10 minutes that refactored the way we setup some of our specs.
How mature is the product that the team is working on?
I think as a product (or core dependency) becomes more mature code reviews are immensely valuable. It also seems to become an issue when new members of the team are still getting their bearings. When a new member joins my team I generally book time explicitly for reviewing not only code but the development process that they follow. This helps suss out any issues they may have with environment, workflow , etc.
The product is mature enough to warrant all of those things, and when new members of the team are on-boarded, time is certainly carved out for code orientation. However, being forced to work on a story from beginning to end with a team member who knows how to pair well and knows the code base well is even more valuable in the end. Pairing is absolutely the best way to share knowledge, as it is necessary for the pair to be successful.
Maybe there's a list of preconditions which help improve a team's chances for successful adoption?
I can imagine teams where pairing unleashes creativity, resourcefulness; and teams where it'd be intolerable.