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

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

On Thu, Oct 1, 2015 at 10:51 PM Adam Sroka [email protected]
[SCRUMDEVELOPMENT] <[email protected]> wrote:

>
>
> 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] [SCRUMDEVELOPMENT] <
> [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
>>
>>
>>
> 
>