[SCRUMDEVELOPMENT] Does your development team do code review? Or do you wish you could? I've a few questions and would like your input.

[Wouter Lagerweij [e-mail] [SCRUMDEVELOPMENT]]

Hi Esther,

As you can see from some of the other responses, code-reviews are not
always popular, and not everyone would want to convince managers to do
them. I could also wonder about the health of organisations where
management should need to be convinced about internal team practices, but I
know those exist.

Code reviews don't have to be bad, in my opinion, but they usually are.

My answer to your request: The one thing that managers, and teams, should
understand about code reviews, is that they're not reviews.

They are not separate stages in the flow that brings code to production.
They can't be, as that kind of interruption in that flow would seriously
slow down development. It could also encourage recklessness/less focus on
quality by providing an unnecessary safety-net, in the same way a
testing-after-coding phase does. It would also, as others have pointed out,
be too late in the flow to be very useful.

As a result, they are also not about a single commit/pull-request, or about
the work of a single developer. It would generate resistance from de
developer. It also has a risk of devolving into various team dysfunctions,
like the code-review-gatekeeper so often encountered.

A good code-review, let's call it a code-reading, is when the team
regularly gets together, goes through some parts of the code that have been
raised as needing some attention, discusses the code (actively reading it,
so making changes as they go along), and learn from that process together.
Results can be changed code, but also changed coding standards, and
certainly a better common understanding of design styles and patterns that
the team uses in their codebase.

Wouter

This probably isn't what you were looking for, but...
I wish more managers understood that code reviews are a remedial stop-gap
for the lack of more radical collaboration like the kind we see with pair
programming and mob programming. The feedback is coming too late, generally
after a complete implementation has already been offered. If we don't act
on it it is waste, and if we do it is failure demand.

A vendor has asked me to write a white paper about the barriers that
developers encounter in doing code reviews – particularly in regard to
getting their managers to care about doing them, or how to sell the boss on
adding it to the development process. (Although it’s sponsored, this is
written for techies, not a commercial for the vendor
 whom I won’t even
mention here.)
That is: I plan to write a genuinely-useful document that you want to
read all the way through. It might be titled, "7 ways to sell the boss on
doing code reviews," or something akin to that.
· What one thing, ONE THING, do you wish the boss (or powers that
be) understood about code review?
· Why did you choose THAT as the one thing to wish for?
Nobody is being quoted here. The closest I might get is to refer to
someone indirectly to give the information credibility, something like,
“Kim, a programmer at a Midwest insurance company, told me about about the
time when
.” So you can speak openly (and privately if you’re more
comfortable). Though I suspect that this might spark a conversation that’d
benefit everybody, so don’t be shy.
It’d help me if you included a LITTLE bit of background for yourself, so
I could include that “programmer at an insurance company” attribution,
should it back up the text.
Also let me know about your experience with code review. Is it something
you use now, but want to improve? Something you’d like to include in your
dev process? What difference would it make to get more support from
Management for doing code reviews?
Incidentally, if you hate code reviews or just aren’t interested
 thanks,
but that doesn’t help me write this piece, which does start with the
premise that code reviews are valuable. So it’s groovy with me if you don’t
find them useful, but I’ll be ignoring that input for the purposes of this
white paper.
--Esther
twitter.com/estherschindler

[Adam Sroka [e-mail] [SCRUMDEVELOPMENT]]

Do them as a group, like an actual review. Put the whole team in a room
with a projector and critique a piece of everybody's work. That way you
actually learn something. Plus, like I said, reviews are a remedy for not
working on the code as a team. So, this is a gentler way to introduce that
versus forcing people to pair.

On the other hand, if you are sitting alone commenting on your teammate's
code with a tool you are certainly doing it wrong. Not only are you missing
an opportunity for a productive conversation, but you are reinforcing a
culture of low fidelity communication and information hiding.

Post by Wouter Lagerweij ***@lagerweij.com [SCRUMDEVELOPMENT]
Hi Esther,
As you can see from some of the other responses, code-reviews are not
always popular, and not everyone would want to convince managers to do
them. I could also wonder about the health of organisations where
management should need to be convinced about internal team practices, but I
know those exist.
Code reviews don't have to be bad, in my opinion, but they usually are.
My answer to your request: The one thing that managers, and teams, should
understand about code reviews, is that they're not reviews.
They are not separate stages in the flow that brings code to production.
They can't be, as that kind of interruption in that flow would seriously
slow down development. It could also encourage recklessness/less focus on
quality by providing an unnecessary safety-net, in the same way a
testing-after-coding phase does. It would also, as others have pointed out,
be too late in the flow to be very useful.
As a result, they are also not about a single commit/pull-request, or
about the work of a single developer. It would generate resistance from de
developer. It also has a risk of devolving into various team dysfunctions,
like the code-review-gatekeeper so often encountered.
A good code-review, let's call it a code-reading, is when the team
regularly gets together, goes through some parts of the code that have been
raised as needing some attention, discusses the code (actively reading it,
so making changes as they go along), and learn from that process together.
Results can be changed code, but also changed coding standards, and
certainly a better common understanding of design styles and patterns that
the team uses in their codebase.
Wouter

This probably isn't what you were looking for, but...
I wish more managers understood that code reviews are a remedial stop-gap
for the lack of more radical collaboration like the kind we see with pair
programming and mob programming. The feedback is coming too late, generally
after a complete implementation has already been offered. If we don't act
on it it is waste, and if we do it is failure demand.

A vendor has asked me to write a white paper about the barriers that
developers encounter in doing code reviews – particularly in regard to
getting their managers to care about doing them, or how to sell the boss on
adding it to the development process. (Although it’s sponsored, this is
written for techies, not a commercial for the vendor
 whom I won’t even
mention here.)
That is: I plan to write a genuinely-useful document that you want to
read all the way through. It might be titled, "7 ways to sell the boss on
doing code reviews," or something akin to that.
· What one thing, ONE THING, do you wish the boss (or powers that
be) understood about code review?
· Why did you choose THAT as the one thing to wish for?
Nobody is being quoted here. The closest I might get is to refer to
someone indirectly to give the information credibility, something like,
“Kim, a programmer at a Midwest insurance company, told me about about the
time when
.” So you can speak openly (and privately if you’re more
comfortable). Though I suspect that this might spark a conversation that’d
benefit everybody, so don’t be shy.
It’d help me if you included a LITTLE bit of background for yourself, so
I could include that “programmer at an insurance company” attribution,
should it back up the text.
Also let me know about your experience with code review. Is it something
you use now, but want to improve? Something you’d like to include in your
dev process? What difference would it make to get more support from
Management for doing code reviews?
Incidentally, if you hate code reviews or just aren’t interested

thanks, but that doesn’t help me write this piece, which does start with
the premise that code reviews are valuable. So it’s groovy with me if you
don’t find them useful, but I’ll be ignoring that input for the purposes of
this white paper.
--Esther
twitter.com/estherschindler

[Nancy Van Schooenderwoert [e-mail] [SCRUMDEVELOPMENT]]

Hi Esther,

Post by Adam Sroka ***@gmail.com [SCRUMDEVELOPMENT]
Do them as a group, like an actual review. Put the whole team in a room
with a projector and critique a piece of everybody's work. That way you
actually learn something. Plus, like I said, reviews are a remedy for not
working on the code as a team. So, this is a gentler way to introduce that
versus forcing people to pair.
On the other hand, if you are sitting alone commenting on your teammate's
code with a tool you are certainly doing it wrong. Not only are you missing
an opportunity for a productive conversation, but you are reinforcing a
culture of low fidelity communication and information hiding.

Just want to "second" what Adam has commented here. My own team moved
from waterfall to Agile by this route and quickly jelled as a team
through holding sessions all together with the code viewable by all on a
projector, as he describes.

We started by holding code reviews according to all the published
advice (because I was convinced by the data on it and thought we should
try it) - we'd set up a meeting, distribute the subject code beforehand,
then all show up to give their comments. It was very hard to schedule
everyone. By the time we did, the comments weren't very valuable. Our
tracking showed that we missed some problems even in the reviewed code.

So we shifted to the live sessions where we'd get together quickly,
make some mods to the code and explain why, and what other options there
were... we'd create some changes to our coding standard when all were
mentally in synch and agreeing on some improved way. This was immensely
valuable, but was no longer a "code review" in the original sense.

In fact, our Agile tests and tripwires in the code were more
effective at catching certain kinds of defects than the reviews were.
Our defect tracking proved that. The group sessions were tops for
creating shared understanding and common purpose. This plus the
automatic tests were why we stopped doing code reviews in the form that
is commonly called a code review. (I also agree with Wouter's comment
that they are not really reviews.)

Essentially, code review is better than cowboy coding, but both are
ancient history. Use a mob programming session.

- njv