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

[[e-mail] [SCRUMDEVELOPMENT]]

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.

So here’s my two questions:

· 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]]

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.

Post by ***@bitranch.com [SCRUMDEVELOPMENT]
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

[Eric Gunnerson [e-mail] [SCRUMDEVELOPMENT]]

I agree. To add a couple more disadvantages:


1) Code reviews take a lot of time; you have to wait for the reviews to come back, and then you have to address the issues and/or discuss the comments with the other developers and perhaps re-review if the changes are big enough. Developers don’t like this downtime, so they optimize by making their code reviews big (“added feature 35 and 36, fixed bugs 3834, 3888, 4013, and refactored rendering engine”), thereby (among other things) making code reviews much less effective.


2) The code review model is poor from a psychological standpoint. The developer is already finished in their mind, and just wants to get the code checked in. The reviewers generally want to do a good job, but they have to divide their time between code reviews (which are rarely allocated scheduled time) and features (which are). Even if reviewers have time to do a deep review, they don’t want to give hard comments because a) it seems mean and b) they have go through the same process themselves. Submitters are in a poor place to take feedback because they are already done, any comments are public demonstrations of what they did wrong, and they are mentally (and many times actually) already coding the next thing.

That means that the process optimizes for the easy-to-find and less impactful issues and makes it less likely to find the important issues that you will regret later on. It makes up for it by being a poor teaching tool to help developers get better.


I have taken to talking about “continuous code review” as one of the benefits that you can get through pairing (and one of the arguments for not requiring a formal code-review process in teams that pair).

Eric
From: ***@yahoogroups.com [mailto:***@yahoogroups.com]
Sent: Thursday, October 01, 2015 1:52 PM
To: ***@yahoogroups.com
Subject: Re: [SCRUMDEVELOPMENT] Does your development team do code review? Or do you wish you could? I’ve a few questions and would like your input.


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.

On Thu, Oct 1, 2015 at 8:42 AM, ***@bitranch.com<mailto:***@bitranch.com> [SCRUMDEVELOPMENT] <***@yahoogroups.com<mailto:***@yahoogroups.com>> wrote:

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.

So here’s my two questions:


• 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<http://twitter.com/estherschindler>

[[e-mail] [SCRUMDEVELOPMENT]]

You're right; it's not what I was looking for. :-)

I've no problem with pair programming, certainly. But it might frustrate you if you asked, "What should the boss know about pair programming?" and I said, "That we should do code reviews!"


An effective and top-quality software development process can include more than one process, right? There's nothing wrong with pair programming _and_ code review? These can exist?


So can we please keep to one topic? and ideally the one I'm asking about?

[Alan Dayley [e-mail] [SCRUMDEVELOPMENT]]

A parable:

A software development manager her people "There is no time to do code
reviews or pair programming. We can't waste time on things that don't
produce code. We have too much to do! Focus on getting the code written and
tested."

The developers and testers quietly nodded and got back to coding and
testing.

Having successfully managed her people, she rushed off to a dentist
appointment. As she sat in the chair she said to the dentist "I know I need
some work done on that tooth. But, I have a lot going on back at the
office. Please save some time and just get to work on the tooth. Don't take
x-rays, don't bother sterilizing the tools. I'm sure I'll be fine if you
just get to work."

The dentist laughed and asked the manager to leave.

</parable>

I wish managers and developers expected each other to be professional in
their skill. That managers and the managers' managers realized that the
professionals they hired know what needs to be done.

Alan

Post by ***@bitranch.com [SCRUMDEVELOPMENT]
You're right; it's not what I was looking for. :-)
I've no problem with pair programming, certainly. But it might frustrate
you if you asked, "What should the boss know about pair programming?" and I
said, "That we should do code reviews!"
An effective and top-quality software development process can include more
than one process, right? There's nothing wrong with pair programming _and_
code review? These can exist?
So can we please keep to one topic? and ideally the one I'm asking about?

[Alan Dayley [e-mail] [SCRUMDEVELOPMENT]]

Esther,

Among many in the Agile world, code reviews are known to be an inferior
practice to better ways of preventing defects and creating quality designs.
Many of us will be reluctant to give arguments in favor of code reviews
simply because we don't want people to do something inferior. The well you
are attempting to draw from might be a bit dry.

Besides, my answer to "What do you wish managers knew about <better
practice X>?" would be similar, whatever X might be.

Alan

Post by ***@bitranch.com [SCRUMDEVELOPMENT]
You're right; it's not what I was looking for. :-)
I've no problem with pair programming, certainly. But it might frustrate
you if you asked, "What should the boss know about pair programming?" and I
said, "That we should do code reviews!"
An effective and top-quality software development process can include more
than one process, right? There's nothing wrong with pair programming _and_
code review? These can exist?
So can we please keep to one topic? and ideally the one I'm asking about?

[Cass Dalton [e-mail] [SCRUMDEVELOPMENT]]

I can tell you what I think most managers think you get out of code reviews

that you don't: defect reduction. Finding defects through code inspection

is very difficult and inefficient.
In my opinion, the single biggest benefit a team gets out of code reviews
is knowledge transfer. It's the same type of knowledge transfer you get
from pair programming (although not as intense), but it is distributed
among all reviewers, not just within a pair. This knowledge transfer has
multiple side effects:
- More people understand more of the code base. Management should care
about this because it reduces institutional knowledge and knowledge silos
- The developers learn from each other. Management should care about this
because, as managers of knowledge workers, knowledge and experience are the
true commodities they are building.
- The conversations also spur design discussions and therefore the team
produces a better product. Management obviously cares about this.


One of the concerns I have heard about code reviews is the amount of time
devoted to process vs actual development. My response to that is that
productivity of knowledge workers can't be measured like assembly line
workers. The time developers spend talking about the design or
whiteboarding is just as valuable as the time they spend banging on the
keyboard. In fact, often an hour of whiteboarding can save 10 hours of
banging on the keyboard.

Post by Adam Sroka ***@gmail.com [SCRUMDEVELOPMENT]
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.

Post by ***@bitranch.com [SCRUMDEVELOPMENT]
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

[Kevin Johnston [e-mail] [SCRUMDEVELOPMENT]]

Maybe they should not be managers of software teams in the first place?

Kevin

Sent from my iPhone

I can tell you what I think most managers think you get out of code reviews that you don't: defect reduction. Finding defects through code inspection is very difficult and inefficient.
- More people understand more of the code base. Management should care about this because it reduces institutional knowledge and knowledge silos
- The developers learn from each other. Management should care about this because, as managers of knowledge workers, knowledge and experience are the true commodities they are building.
- The conversations also spur design discussions and therefore the team produces a better product. Management obviously cares about this.
One of the concerns I have heard about code reviews is the amount of time devoted to process vs actual development. My response to that is that productivity of knowledge workers can't be measured like assembly line workers. The time developers spend talking about the design or whiteboarding is just as valuable as the time they spend banging on the keyboard. In fact, often an hour of whiteboarding can save 10 hours of banging on the keyboard.

Post by Adam Sroka ***@gmail.com [SCRUMDEVELOPMENT]
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.

Post by ***@bitranch.com [SCRUMDEVELOPMENT]
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

[Ron Jeffries [e-mail] [SCRUMDEVELOPMENT]]

Kevin,

Post by Kevin Johnston ***@gmail.com [SCRUMDEVELOPMENT]
Maybe they should not be managers of software teams in the first place?

Maybe. But we gotta work with what we get in that area, mostly.

Ron Jeffries
ronjeffries.com <http://ronjeffries.com/>
Sometimes people just don't want the flower. Sometimes you have to let them walk away.
— Amanda Palmer

[[e-mail] [SCRUMDEVELOPMENT]]

Thanks, folks. It might surprise you, but this really helped me. If nothing else it gave me a sensible and eloquent set of objections that I could use to frame the white paper. ("Experienced developers who are not in favor of code review say THIS.... how do we answer that?")

So I very much appreciate your views, and the time you took to share them.

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

Post by ***@bitranch.com [SCRUMDEVELOPMENT]
You're right; it's not what I was looking for. :-)

Mea culpa ;-)

Post by ***@bitranch.com [SCRUMDEVELOPMENT]
I've no problem with pair programming, certainly. But it might frustrate
you if you asked, "What should the boss know about pair programming?" and I
said, "That we should do code reviews!"
An effective and top-quality software development process can include more
than one process, right? There's nothing wrong with pair programming _and_
code review? These can exist?

Yeah. I've been on teams that do both, usually because they are pretty new
to pairing. Once you are pairing effectively the reviews immediately feel
redundant in a palpable way.

Post by ***@bitranch.com [SCRUMDEVELOPMENT]
So can we please keep to one topic? and ideally the one I'm asking about?

If you aren't practicing collective ownership then code reviews will do
little mitigate the effects. If you are then code reviews are a waste of
time. So, they are a stop-gap. That is something I wish managers understood
about them.

Stop-gaps are not bad things as long as they don't become codified
practice. They should be transitional.

As a transitional practice code reviews can be effective if done
face-to-face preferably with the whole team present.

[Ron Jeffries [e-mail] [SCRUMDEVELOPMENT]]

Hi Esther,

Post by ***@bitranch.com [SCRUMDEVELOPMENT]
· 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?

As you’re finding here, the well is pretty dry for support for code reviews. The practice was shown to be useful and practical decades ago, probably more than two. This was in the day when computer time was expensive and computer programmers less so.

There’s no doubt that code reviews, done well, are effective in finding at least some kinds of problems. They are very difficult to do effectively, for reasons mentioned here. I had my teams doing code reviews, after training in how to do them, some years back, like in the 80s. My favorite reasons why they didn’t work very well include:

The programmer who wrote the code think he’s done and therefore feels the need to defend his work against these people who do not understand the problems he had to deal with. He’s not always wrong about that.
The reviewers in fact do not understand the problems the programmer had to deal with, and much of what they offer will in fact be not very useful.
The reviewers all have real work to do and are under pressure as always. The standard reviewer behavior at the review meeting becomes to spot one thing, perhaps a poorly named variable, or maybe even a good idea if they see something. Then they wait until that page of code is being reviewed, offer their idea, and they’re good to go.
You can’t really review a big bolus of code. It’s not like editing text (which is hard enough, as you know): it’s much harder, because it has to actually run on a computer. So reviews are either too frequent to tolerate, or covering so much code that they are superficial.
They’re not fun for the reviewer and even less fun for the reviewed.

I get that this isn’t helping. But as I see it — and I’ve been a strong enough supporter of code reviews to get people trained in them and to require them until it was clear they weren’t working — they’re mostly not on.

I gather the people you’re writing this for are in the business of code reviews, somehow. If I were invited to write an article supporting code reviews, i wouldn’t. But I’m not in your business. The best I could say might be something like this:

Code reviews have been shown to be effective when done well, particularly as regards discovery of defects. (My recollection is that they are less effective at identifying and fixing architectural or design issues.)
Code reviews will improve code readability a bit (see remarks above about how people review).
Code reviews probably give everyone a better view of the larger system (though not as good a view as actually working on it all, as in pair or mob programming).
Live reviews looking at the screen, and ideally actually making changes, can be useful. (They amount to mob programming if you’re actually running the code.)

Post by ***@bitranch.com [SCRUMDEVELOPMENT]
· What one thing, ONE THING, do you wish the boss (or powers that be) understood about code review?

Code reviews, especially imposed, especially under pressure, will provide some small value, much less than the sort of teamwork that comes from modern Agile methods, pair programming, and mob programming.

Post by ***@bitranch.com [SCRUMDEVELOPMENT]
· Why did you choose THAT as the one thing to wish for?

I care about results, and I care about the people who do the work, and if management understood that they might be more likely to set up a situation that works better for both sides.

Good luck!

Ron Jeffries
ronjeffries.com <http://ronjeffries.com/>
Sometimes I give myself admirable advice, but I am incapable of taking it.
-- Mary Wortley Montagu