5 ms·

Pairing vs. Code Review: Comparing Developer Cultures

28 points by phinze 13y ago

southpawgirl 13y ago
I don't see the two practices as antithetical: complex features with a lot of potential pitfalls take advantage from pair programming; code reviews are perfect for BAU tasks. I am a bit suspicious of the ecstatic tone that the author has while writing about pair programming: I am not sure I ever met someone who deeply enjoys it; at best it's seen as good practice, or a necessary evil.
- drewolson 13y ago
  I'm confused, you're questioning the author's sincerity in expressing his own enjoyment of pair programming? I deeply enjoy pairing. I know quite a few folks that do as well.
  - southpawgirl 13y ago
    Ok, fine then :) I admit I've never met anyone so genuinely enthusiastic about pair programming, so it sounds unusual to me.
    - elliotf 13y ago
      Give it a go sometime. It's the most fun I've had at a job.
- drfatbooty 13y ago
  I worked with the author at last_job and can attest to the genuineness of his tone. Pairing is pretty fun when you like your coworkers.
- ssgelm 13y ago
  I definitely genuinely enjoy pair programming as long as it's with the right person. In the end it's all about who you are working with.
simonista 13y ago
Great post! In the pairing paradigm (say that 5 times fast), how much of a typical day is spent actually pairing? How do you manage email or other company wide communication? What happens when a server crashes or another emergency comes up? Or when another pair has a question that you can answer? Or when one member of the pair is also responsible for a deploying something? Or one member has a meeting? Disclaimer: I've mostly been exposed to the code review paradigm (I work with Paul at `current_job`)
- JoshTriplett 13y ago
  I've done pair programming extensively, both for personal projects and at work. Pair-programming sessions are not the time to process email; IMs/IRC are treated as interrupts (quickly check if an urgent response is needed and otherwise defer); meetings are something you schedule pair-programming sessions around; deployments are a great thing to do as a pair to reduce screwups.
- makmanalp 13y ago
  Usually pairing seems to work great to get you through things that seem like they're a slog. So you don't have to pair through everything, just the hard and boring bits. It helps to timebox it, and say it's going to be (e.g.) an hour long session to prevent it from taking forever and help focus. Even if you're not done, chances are you'll have made good progress. So, schedulingwise, it's a bit like a meeting. The largest benefit I see is that having someone with you is like having more than double the focus and vigilance, since you're both there to help each other out and you'll both tell each other when you're leading yourselves astray, which doesn't happen when programming individually. Pair-design also works great. I think it's harder to be as productive in code review (and I think they aren't mutually exclusive anyway) because people tend to focus more on nitpick changes like style issues, and miss the larger design stuff.
  - simonista 13y ago
    Sure, but my question was in the context of the OP definition of "pair programming culture" as "a team that does nearly 100% pairing ... The day-to-day experience of programming is that of a day-long conversation with your pair" I'm curious how other things that are intrinsically non-pair activities fit in.
judk 13y ago
A problem with code review is that people treat is as proofreading a final project, so it isn't effective for collaboration before a solution is obvious and quick to code up. We need more informal/preliminary ways to code-review work in progress
- stonith 13y ago
  I work on Openstack, which uses gerrit for review. We use blueprints in launchpad to do preliminary design, then reference the blueprint in the commit message, and frequently people working on patches with hacky implementations will mark it as WIP, which is basically a signal not to approve but to provide feedback. One thing the article didn't mention is that code review works across companies and is ideal for open source work.
w_t_payne 13y ago
Great post. We use Gerrit code review, with side-by-side reviews. I.e. the developer pushes to Gerrit, then sits down with the reviewer and walks him through the code. 99% of the bugs are found by the original developer -- after he is forced to explain what he did (and why) to a colleague. I think that this gets you at least some of the benefits of both approaches.
- phinze 13y ago
  This is an interesting practice, thanks for sharing. I'm really curious about different sorts of hybrid approaches being used in the wild. I'd be curious to hear how the day-to-day schedule ends up working out between developers, since the review process is synchronous in this case.
  - w_t_payne 13y ago
    The synchronous aspect is a problem, although not a huge one. The issue is mitigated to a certain extent by excluding non-customer facing research & testing components from the review requirement. Also, the architecture of the system is such that people tend to work very independently, with little-to-no overlap, so reviews can be postponed with little impact on velocity. As our team grows in size, we could also think about instituting a rotating code reviewer responsibility, with team members taking it in turns to act as the designated reviewer for the day.
- jeffdavis 13y ago
  Unfortunately the explanations aren't left as code comments, so they may be lost. One ting nice about code review is that the code must stand on its own to pass. That means that it's likely to be understandable a year from now.
  - w_t_payne 13y ago
    Written documentation does have the advantage of being persistent, and supports an unlimited producer-to-consumer fan-out. However, documents have a pretty lousy bandwidth and knowledge retention rate compared to face-to-face communication. If you are working in a small team with low staff turnover, face-to-face beats written docs hands-down as a knowledge transfer mechanism. On the other hand, if your staff turnover is high, or if your team is huge, then you absolutely need to write everything down. I am working in a small team, with low turnover, so face-to-face works best for us in this particular instance. (We still document what we do pretty well, though, with both regular source commentary and tools like Doxygen, but as a matter of professional pride rather than necessity).
elliotf 13y ago
An unrelated note to the author: Please contemplate adding an RSS/Atom feed so that your blog may be easily followed.
- phinze 13y ago
  Done! http://phinze.github.io/rss.xml http://phinze.github.io/rss.xml
  - elliotf 13y ago
    Thank you!
cosinewave 13y ago
Well written and informative. Starting the read, I was somewhat skeptical of the pairing approach but now I see how it can work and work well.
jdost 13y ago
Great read! Upon finishing, the two sides seem to be opposite solutions of a good problem (that is getting a non singular path to guarantee code quality). It seems that the best solution is a mixed approach. Using pairs to gain the benefits of knowledge sharing and sort of check ups (that is having a second pair of eyes to achieve the intermediate commit/review issue). But also using a large amount of solo coding with code reviews to ensure overall quality without missing out on the non-pairing types. Has anyone ever tried a balanced approach like this? Such as spending 2-3 days each week pairing on a part of a project to help with knowledge sharing, best practices, or possible bad paths, and then the rest solo coding with some final code reviews? Also, what is the best form of code review? Is it having a single developer be assigned to perform a code review for each pull request or for it to have some gestation period for crowd comments to come in, or even some voting quota/discussion until a simple consensus is reached? There seems to be some room for a variety of time/quality trade offs (in theory, more eyes == higher quality, more time).
voidr 13y ago
A lot of the time pair programming and code reviews could be simply automated, which I find infinitely more efficient. If it can't be automated that may be a sign of a bad architecture/tooling.

28 points by phinze 13y ago

I don't see the two practices as antithetical: complex features with a lot of potential pitfalls take advantage from pair programming; code reviews are perfect for BAU tasks. I am a bit suspicious of the ecstatic tone that the author has while writing about pair programming: I am not sure I ever met someone who deeply enjoys it; at best it's seen as good practice, or a necessary evil.

drewolson 13y ago
I'm confused, you're questioning the author's sincerity in expressing his own enjoyment of pair programming? I deeply enjoy pairing. I know quite a few folks that do as well.
- southpawgirl 13y ago
  Ok, fine then :) I admit I've never met anyone so genuinely enthusiastic about pair programming, so it sounds unusual to me.
  - elliotf 13y ago
    Give it a go sometime. It's the most fun I've had at a job.
drfatbooty 13y ago
I worked with the author at last_job and can attest to the genuineness of his tone. Pairing is pretty fun when you like your coworkers.
ssgelm 13y ago
I definitely genuinely enjoy pair programming as long as it's with the right person. In the end it's all about who you are working with.

simonista 13y ago

Great post! In the pairing paradigm (say that 5 times fast), how much of a typical day is spent actually pairing? How do you manage email or other company wide communication? What happens when a server crashes or another emergency comes up? Or when another pair has a question that you can answer? Or when one member of the pair is also responsible for a deploying something? Or one member has a meeting? Disclaimer: I've mostly been exposed to the code review paradigm (I work with Paul at `current_job`)

JoshTriplett 13y ago
I've done pair programming extensively, both for personal projects and at work. Pair-programming sessions are not the time to process email; IMs/IRC are treated as interrupts (quickly check if an urgent response is needed and otherwise defer); meetings are something you schedule pair-programming sessions around; deployments are a great thing to do as a pair to reduce screwups.
makmanalp 13y ago
Usually pairing seems to work great to get you through things that seem like they're a slog. So you don't have to pair through everything, just the hard and boring bits. It helps to timebox it, and say it's going to be (e.g.) an hour long session to prevent it from taking forever and help focus. Even if you're not done, chances are you'll have made good progress. So, schedulingwise, it's a bit like a meeting. The largest benefit I see is that having someone with you is like having more than double the focus and vigilance, since you're both there to help each other out and you'll both tell each other when you're leading yourselves astray, which doesn't happen when programming individually. Pair-design also works great. I think it's harder to be as productive in code review (and I think they aren't mutually exclusive anyway) because people tend to focus more on nitpick changes like style issues, and miss the larger design stuff.
- simonista 13y ago
  Sure, but my question was in the context of the OP definition of "pair programming culture" as "a team that does nearly 100% pairing ... The day-to-day experience of programming is that of a day-long conversation with your pair" I'm curious how other things that are intrinsically non-pair activities fit in.

judk 13y ago

A problem with code review is that people treat is as proofreading a final project, so it isn't effective for collaboration before a solution is obvious and quick to code up. We need more informal/preliminary ways to code-review work in progress

stonith 13y ago
I work on Openstack, which uses gerrit for review. We use blueprints in launchpad to do preliminary design, then reference the blueprint in the commit message, and frequently people working on patches with hacky implementations will mark it as WIP, which is basically a signal not to approve but to provide feedback. One thing the article didn't mention is that code review works across companies and is ideal for open source work.

w_t_payne 13y ago

Great post. We use Gerrit code review, with side-by-side reviews. I.e. the developer pushes to Gerrit, then sits down with the reviewer and walks him through the code. 99% of the bugs are found by the original developer -- after he is forced to explain what he did (and why) to a colleague. I think that this gets you at least some of the benefits of both approaches.

phinze 13y ago
This is an interesting practice, thanks for sharing. I'm really curious about different sorts of hybrid approaches being used in the wild. I'd be curious to hear how the day-to-day schedule ends up working out between developers, since the review process is synchronous in this case.
- w_t_payne 13y ago
  The synchronous aspect is a problem, although not a huge one. The issue is mitigated to a certain extent by excluding non-customer facing research & testing components from the review requirement. Also, the architecture of the system is such that people tend to work very independently, with little-to-no overlap, so reviews can be postponed with little impact on velocity. As our team grows in size, we could also think about instituting a rotating code reviewer responsibility, with team members taking it in turns to act as the designated reviewer for the day.
jeffdavis 13y ago
Unfortunately the explanations aren't left as code comments, so they may be lost. One ting nice about code review is that the code must stand on its own to pass. That means that it's likely to be understandable a year from now.
- w_t_payne 13y ago
  Written documentation does have the advantage of being persistent, and supports an unlimited producer-to-consumer fan-out. However, documents have a pretty lousy bandwidth and knowledge retention rate compared to face-to-face communication. If you are working in a small team with low staff turnover, face-to-face beats written docs hands-down as a knowledge transfer mechanism. On the other hand, if your staff turnover is high, or if your team is huge, then you absolutely need to write everything down. I am working in a small team, with low turnover, so face-to-face works best for us in this particular instance. (We still document what we do pretty well, though, with both regular source commentary and tools like Doxygen, but as a matter of professional pride rather than necessity).

elliotf 13y ago

An unrelated note to the author: Please contemplate adding an RSS/Atom feed so that your blog may be easily followed.

phinze 13y ago
Done! http://phinze.github.io/rss.xml http://phinze.github.io/rss.xml
- elliotf 13y ago
  Thank you!

cosinewave 13y ago

Well written and informative. Starting the read, I was somewhat skeptical of the pairing approach but now I see how it can work and work well.

jdost 13y ago

Great read! Upon finishing, the two sides seem to be opposite solutions of a good problem (that is getting a non singular path to guarantee code quality). It seems that the best solution is a mixed approach. Using pairs to gain the benefits of knowledge sharing and sort of check ups (that is having a second pair of eyes to achieve the intermediate commit/review issue). But also using a large amount of solo coding with code reviews to ensure overall quality without missing out on the non-pairing types. Has anyone ever tried a balanced approach like this? Such as spending 2-3 days each week pairing on a part of a project to help with knowledge sharing, best practices, or possible bad paths, and then the rest solo coding with some final code reviews? Also, what is the best form of code review? Is it having a single developer be assigned to perform a code review for each pull request or for it to have some gestation period for crowd comments to come in, or even some voting quota/discussion until a simple consensus is reached? There seems to be some room for a variety of time/quality trade offs (in theory, more eyes == higher quality, more time).

voidr 13y ago

A lot of the time pair programming and code reviews could be simply automated, which I find infinitely more efficient. If it can't be automated that may be a sign of a bad architecture/tooling.