Examining Code Review Myths

Alexander Pope once opined that a little learning can be a dangerous thing. ?When we learn just enough to hear something that suits our agenda, we have a cognitive bias that encourages us to stop right there. ?Quit while you’re ahead, as it were.

This dynamic gives rise to misconceptions. ?They go by various names: urban legends, myths, canards, tall tales, etc. ?Obviously, this occupies a prominent role in our world, to have such a rich tapestry of synonyms.

I won’t delve any further into the psychology behind this. ?That’s not my area of expertise. ?But I would like to recount (and clear up) some of the myths I hear about code review in my travels.

As a consultant, I find myself in a lot of software shops, observing a lot of people. ?As a result, I feel as though I have a particularly rich set of misconceptions from which to draw. ?IT management consultants are usually there either to drive change or to act as incidental parties to it. ?That change makes people uneasy, which causes objections to surface. ?Some of those objections are perfectly legitimate. Some of them are nonsense.

Let’s focus today on the nonsense. ?What are some code review myths?

We Pay You To Code, Not To Chat

For the first myth, I’ll pick one that usually originates from leadership. ?It involves an anachronistic view of the nature of programming and knowledge work in general. ?And you find it most commonly in places that regard building software as akin to assembling widgets or constructing buildings. ?In other words, they view it as an analog of manual labor.

When folks have this outlook, you get pushback on things they consider non-essential activities. ?Naturally, this includes code review and pair programming. ?Someone has already written the code, and you’ve got QA to catch any problems. ?We pay you to code, not to talk about the code you wrote.

Of course, this ignores the knowledge-work nature of programming. ?Peer review more than pays for itself in terms of mistakes caught and downstream issues avoided. ?But you can explain this in a better way, I’ve found. ?When you have old-school managers who always want to optimize for “hands on keyboards” time, ask them whether or not they include word-per-minute typing tests as part of their interview process. ?Oh, no? ?Why not? ?Could it be that a lack of time spent clacking away at a keyboard isn’t?really the bottleneck for programmer productivity?

Code Reviews Have to Be Official and Formal

Another myth you’ll frequently run across involves not the value of the activity but the nature of it. ?A lot of people seem to think that code reviews have to be incredibly formal affairs, complete with cited sources and pass or fail grades. ?This notion finds its most willing audience in the enterprise, where team members have to worry about compliance and other highly bureaucratic concerns. ?And frankly, humans tend to respond to bureaucracy with formalism.

But code review needn’t resemble a constitutional convention. ?You can leave your quorums, parliamentary procedure, and official wigs at home. ?Instead, you’re really just looking to get some eyeballs on your work for sanity checks, feedback, and tips for how to improve your work.

In fact, I’ve found that formal code reviews tend to get fairly counterproductive. ?They can encourage mindless box-checking, as well as unpleasant politics among participants. ?Now, that won’t necessarily happen, but you do see it more often with formal, bureaucratic reviews than with more humanized collaboration.

So do your best to keep your code reviews friendly and collaborative, the way you might expect them to go if a friend came over and asked, “What do you think of this?”

You Don’t Need Code Reviews If You Have Unit Tests

I practice test driven development (TDD). ?As a result, you’ll find me writing unit tests. ?A?lot of unit tests. ?So if you’d expect anyone to tell you that unit tests cure all that ails ya, you would expect me to. ?But I won’t.

Unit tests are a great tool and, if you don’t already, you should start writing them. ?But unit tests don’t solve all of the world’s problems. ?As they say, there are no silver bullets in software. ?So I cringe when I hear people hold unit tests up as an alternative to performing code reviews.

The activities certainly have some overlap, but they solve fundamentally different problems. ?Code review involves checking for mistakes, sure. But more generally, it involves evaluation of the source code. ?This is, inherently, a compile-time concern. ?Code reviewers examine the code, make deductions, and offer feedback on that basis.

Unit tests, on the other hand, execute the compiled code and make and record runtime observations. ?They don’t deduce anything at all about your code, content instead to document its behavior. ?Unit tests serve well to guard against regressions and communicate design intent. ?They exist to allow you to change your code with the confidence that you won’t break things. ?But they won’t tell you anything beyond that.

Code Review Requires a Lot of Developer Time

This myth resembles the first one a bit, but with an important difference. ?The first myth represented a misunderstanding of the value of the code review activity itself. ?This one instead involves a misunderstanding of how much time it must take.

Shops with more formalized procedures tend also to have reviews that take forever. ?And so a lot of developers come to view this as an inevitability of the practice itself. ?But that’s not the case. ?You can have very succinct reviews, particularly if you commit frequently, in small batches, and ask for reviews in the same fashion.

And reviews need not happen in person. ?You can send requests digitally and asynchronously, economizing even more on your time. ?Or you can use tools that automate an impressive array of checks on your code as well.

You may find yourself pressed for time and in a pinch. ?But don’t use that as an excuse not to have reviews. ?Just have adaptable review processes that you can scale up or down as your time allows. ?If you assume that they take forever, you’ll find yourself with a constant, ready-made excuse not to get feedback.

Moving Beyond Code Review Myths

No doubt you’ve seen some misconceptions in your travels, too. ?The myths are so many, I couldn’t possibly list everything here.

To get beyond misconceptions — and myths in general — make sure you keep a pragmatic view of things. ?No matter what procedures companies may have in place, remember that a code review is as simple as asking a peer (or a tool) to take a look and offer you feedback. ?And as with any kind of knowledge work, feedback is important to helping you catch mistakes, exchange ideas, and grow in your knowledge.

So cut through the wrong-headed notions that you might encounter and define something that makes sense for you, given your time constraints and your process. ?But make sure you do it in some fashion, or you’re leaving open a huge blind spot.

Learn more how CodeIt.Right can help you automate code reviews and improve the quality of your code.

About the author

Erik Dietrich

Website

I am Erik Dietrich, founder of DaedTech LLC, programmer, architect, IT management consultant, author, and technologist.

This author does not have any more posts.