Pairing vs. Code Review: Comparing Developer Cultures(phinze.github.io)
phinze.github.io
Pairing vs. Code Review: Comparing Developer Cultures
http://phinze.github.io/2013/12/08/pairing-vs-code-review.html
24 comments
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.
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.
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.
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.
I'm curious how other things that are intrinsically non-pair activities fit in.
In my experience, a day spent pairing, while generally a sort of intense experience, is also filled with little breaks. Your pair gets up to grab a drink; you check your email; somebody turns on a Katy Perry single and you spin around to join a team-wide argument about its merits; etc, etc. :)
While nearly 100% of your time is _dedicated_ to pairing, I'd say the percentage of time you both spend actively sitting at the computer working on a task is roughly equivalent to what you'd do as an individual. Which is to say, it varies. But it never really feels like you can't do side things; the vibe is very flexible and casual.
For deploys and emergencies, it's almost always a pair attacking the problem. Even if just one developer is doing most of the driving, the pair is still able to learn, catch typos, diagnose, etc.
Meetings can definitely end up splitting pairs, which becomes yet another incentive to try to minimize them.
While nearly 100% of your time is _dedicated_ to pairing, I'd say the percentage of time you both spend actively sitting at the computer working on a task is roughly equivalent to what you'd do as an individual. Which is to say, it varies. But it never really feels like you can't do side things; the vibe is very flexible and casual.
For deploys and emergencies, it's almost always a pair attacking the problem. Even if just one developer is doing most of the driving, the pair is still able to learn, catch typos, diagnose, etc.
Meetings can definitely end up splitting pairs, which becomes yet another incentive to try to minimize them.
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).
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).
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.
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.
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.
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.
I deeply enjoy pairing. I know quite a few folks that do as well.
Ok, fine then :) I admit I've never met anyone so genuinely enthusiastic about pair programming, so it sounds unusual to me.
Give it a go sometime. It's the most fun I've had at a job.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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
We need more informal/preliminary ways to code-review work in progress
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.
One thing the article didn't mention is that code review works across companies and is ideal for open source work.
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.
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.
An unrelated note to the author: Please contemplate adding an RSS/Atom feed so that your blog may be easily followed.
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`)