Information Technology Dark Side

Hello David,

I am just checking with you to find out what your perspective is on “code reviews” in a Scrum environment? Generally it seems that I see that the discussion on this leans toward paired programming and test driven development to meet this need. But I would be very interested to get your opinion since you have been working in the Scrum environment.

Thank you!

Susan McCoy

Here’s the answer I sent her:

Good question. It’s my opinion that most code reviews are performed too late in a project to do much about serious problems. This seems to be true regardless of PM approach. If you have that problem, you need to fix it or just stop wasting time on code reviews.

I haven’t used a lot of pair programming, but I have done it, particularly with junior people. It seemed to work out well enough, and the two team members who trained each other this way became top-notch coders.

I haven’t really done formal code reviews much at all (except when required to by a process nazi) and don’t value them much. IMO, formal code reviews probably have the least value in agile environments, because the code is changing so quickly and is frequently re-written multiple times (a good thing, I think). I prefer to simply develop a team with one really good coder who also is a great mentor, and several junior people who need mentoring. When structured that way, code reviews tend to happen naturally and early. It’s hard to find a leader like that, but that’s where I would put my focus.

I hope this helps.

Is this the second email in a row where I’ve answered the question without actually answering the question. I hope not.

- Dave

If you enjoyed this post, make sure you subscribe to my RSS feed!

Stumble it!