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

Hi Esther,

> On Oct 1, 2015, at 11:42 AM, [email protected] [SCRUMDEVELOPMENT] <[email protected]> wrote:
> 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?
> 
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.)

Nonetheless my answers are:
> ·      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.
> ·      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