4 Reasons Developers Resist Code Review (and Why They Shouldn’t)

Statistics show that code review works and improves software quality. Yet plenty of developers are reluctant to employ the practice on their own teams. Here’s why developers avoid code reviews… and why they ought to change their minds.

140458174As Captain John-Luc Picard said after he was assimilated by the Borg, “Resistance is futile.” His point? You can’t change the path of least resistance. There are some inescapable truisms, whether you’re traveling at light-speed on the U.S.S. Enterprise fleeing from the Borg or you’re ruminating about meta-classes as you toil away creating fabulous software.

What exactly does this have to do with code review? Code review is a frequently disparaged quality process. Yet statistics prove that code review significantly improves software quality and reduces technical debt. On some intuitive level, you have to figure that by definition, code review saves money.

So why do development teams continue to resist it? See my reasons, following the infographic…

Code review value

Cultural issues present a huge impediment. Lots of developers hate code reviews, because they can’t forget tortuous review meetings. Or worse, they were berated by management for creating poor code (which is a sign of poor management, not bad coding). A code review is an opportunity for the team to improve itself, and should be viewed in that light; it is not an opportunity to belittle one’s coworkers.

Another possibility is that code review focuses on interaction and collaboration, an activity that management sometimes misconstrues as “chatting” when there’s code to be written! Agile teams have discovered that interaction and collaboration are both critical to create working software fast. To that end, they do code reviews; it’s a secret to their success.

Jeff Sutherland works with a venture capital firm, OpenView Partners, that mandates the use of code review at all their portfolio companies. You can hear Jeff discuss this in detail in his recent webinar Secrets of High Quality Development with Scrum Co-creator Jeff Sutherland.

A third possibility is the misconception that static analysis tools find every bug, so code review is unnecessary. But that’s not true. Capers Jones, a giant in the area of software quality metrics, says in his paper Combining Inspections, Static Analysis and Testing to Achieve Defect Removal Efficiency Above 95% that the highest software quality can only be achieved using a three-pronged approach. Static analysis is only one prong. “A synergistic combination of formal inspections, static analysis and formal testing can achieve combined defect removal efficiency levels of 99%,” Jones writes.

Static analysis tools have significant limitations, including an inability to identify some code as suspect. For example, static analysis does not flag a function like this, because it doesn’t know that a function named getRandomNumber should not always return the same value (with a hat tip to XKCD).

Int getRandomNumber()
return 4; //chosen by fair dice roll.
//guaranteed to be random

Probably the biggest obstacle of all in the adoption of code reviews is fear. Fear of missing deadlines. Fear of distraction. Fear of investing time that developers don’t have. Which is a shame, since the intent of a code review is to maximize code quality during up-front development and to decrease development time dedicated to code rework.

My point: Invoking a process that fosters collaboration, provides mentoring and skill development, encourages familiarity with the code base, and ultimately improves software quality is great. But make sure it’s lightweight and fun. If you want to ship better code faster, consider incorporating code review into your arsenal of quality tools. Once you get used to it – and I’ve learned from many tool-assisted code review users that, “we can’t imagine coding without it” — I think you’ll find it valuable too! Remember, resistance is futile!



Speak Your Mind