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.

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: [email protected] [mailto:[email protected]]
Sent: Thursday, October 01, 2015 1:52 PM
To: [email protected]
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, [email protected]<mailto:[email protected]> [SCRUMDEVELOPMENT] <[email protected]<mailto:[email protected]>> 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>