
Pairing vs. Code Review: Comparing Developer Cultures - phinze
http://phinze.github.io/2013/12/08/pairing-vs-code-review.html
======
simonista
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`)

~~~
makmanalp
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
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.

------
jdost
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).

------
southpawgirl
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
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
Ok, fine then :) I admit I've never met anyone so genuinely enthusiastic about
pair programming, so it sounds unusual to me.

~~~
elliotf
Give it a go sometime. It's the most fun I've had at a job.

------
w_t_payne
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
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
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.

------
judk
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
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.

------
voidr
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.

------
cosinewave
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.

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

~~~
phinze
Done! [http://phinze.github.io/rss.xml](http://phinze.github.io/rss.xml)

~~~
elliotf
Thank you!

