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

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.

On Thursday, October 1, 2015, Wouter Lagerweij [email protected]
[SCRUMDEVELOPMENT] <[email protected]> wrote:

>
>
> 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]
> <javascript:_e(%7B%7D,'cvml','[email protected]');> [SCRUMDEVELOPMENT]
> <[email protected]
> <javascript:_e(%7B%7D,'cvml','[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]
>> <javascript:_e(%7B%7D,'cvml','[email protected]');> [SCRUMDEVELOPMENT]
>> <[email protected]
>> <javascript:_e(%7B%7D,'cvml','[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
>>>
>>>
>>>
>> 
>