Comments on: Code reviews are overrated

By: AlenZukich

AlenZukich — Thu, 04 Jun 2009 14:16:55 +0000

IMHO code reviews are essential. Perhaps it might not work with every s/w organization but the next time I fly on the Boeing 777 I want to feel reassured that there was some formal code review process. The bottom line is that code reviews are proven to eliminate bugs and provide better code.

As for the process, well there are automation tools. Start pairing that up with static analysis and you have one hell of a bug finding machine: http://kloctalk.klocwork.com/?p=173

By: abby, the hacker chick blog

abby, the hacker chick blog — Thu, 04 Jun 2009 00:33:19 +0000

I think you’re right that anything we can do to make programmers more conscious of the fact that others are going to be reading their code (by extending and integrating with it! forget for the purpose of “code reviews”, who cares?) and to therefore take the extra time to make it readable is a Good Thing.

I do, however, think code reviews can be beneficial. The problem is just that we like to add so much damn baggage around them.

Drop the baggage, keep the focus on the end goal – better quality code – and keep it informal, lightweight, and something people can do on their own time (not adding distractions, as you mention).

My favorite code review tip (thanks to Uncle Bob ala Clean Code) is – if you see an issue when reviewing someone else’s code, don’t go right a paragraph about it or publicly out them on it in a conference room. Instead, just think about how it could be cleaner/less ambiguous/more correct and then CHANGE IT. Of course, then you want to let them know what you changed and why – but this is much more efficient, and gives the original coder an opportunity to learn how to make his code more correct and/or understandable to others in the future.

By: Gregg Sporar

Gregg Sporar — Wed, 03 Jun 2009 18:52:54 +0000

“The emails were automated….”

And that’s the key: automation can remove the downside. In other words, use automation to avoid wasting developer time *and* to avoid interrupting people. Because as you point out, those interrupts are expensive.

You can roll your own automation, or buy a tool like ours (http://smartbear.com/codecollab.php) or one of the other peer code review tools (and there are some that are open source). But the bottom line is the same: if you remove the overhead of meetings and interruptions, etc., code review pays big dividends. For more, see: http://smartbear.com/docs/CaseStudy-Cisco.pdf

By: judah

judah — Wed, 03 Jun 2009 18:10:03 +0000

This is the only valid measurement of code quality, http://e1.simplecdn.net/slashw/measurement-of-code-quality.jpg.

http://slashweb.org/programming/25-best-programmer-webcomic-strips.html

By: Preston Lee

Preston Lee — Wed, 03 Jun 2009 07:00:45 +0000

Some thoughts on pairing from a business standpoint..

http://www.prestonlee.com/2009/06/02/prestons-business-razor-a-stakeholder-perspective-on-pair-programming/

By: nahmel

nahmel — Tue, 02 Jun 2009 23:01:01 +0000

Well, if you really care that the code must work, you just _do_ code review. And even more. And to not be disrupted you use GIT (or something that can give you the same flow). You use emails.

Of course there is no silver bullet and of course an insance amount of just code review is just insane. So what did you proved?

By: Ivo

Ivo — Tue, 02 Jun 2009 20:01:24 +0000

I have the same experience as Senko: a ‘code review’ is nothing more than asking a colleague (by email or in some other ignorable way) to review a specific set of changes you checked into CVS/SVN/… The review is performed at a time of his choosing. I have found these reviews to be very helpful, catching more bugs than I would like to admit to.