After a good discussion with a colleague for the merits of code review I thought I should give some of the reasons I use as to why a development team should adopt a code review process.
One of the big problems with long-running development projects, especially big ones, are that knowledge around certain areas tend to pile up on certain people, creating “knowledge silos”. Unfortunately, this process is also self-perpetuating, as people tend to draw to working with things they know, and avoid what they don’t know. Starting a code review process won’t even out this landscape completely, but it will give people enough of a boost to dare venture into the code by themselves, hopefully breaking any negative spiral that may have been created. It also helps bring new members of the team into the code base quickly.
Have you ever worked with “that guy”, the one who treats the code like his own baby, and treats the developers who dare edit it as somebody who just beat up their baby? This is by far my biggest pet peeve. A code review process won’t necessarily change someone’s personality, but forcing people to let go of their code and leave it out for criticism might very well change their perception of code ownership. From the other perspective, a reviewer is well aware that they are as much responsible for the code that is submitted to the code base as whoever wrote it, hopefully increasing their sense of personal responsibility and ownership for the code, even if they didn’t write a single line of it.
Actually forcing the team to justify their code, and explain it to others opens up new channels of communication, that may well extend beyond the code review system. It invites the whole team to discuss code decisions regarding the product, or at least question them. This is very related to the increased sense of shared code.
I guess this is the most obvious win that a code review system will bring. Having someone else watch over your code not only forces you to write good, understandable code, but also brings a different perspective to the problem you are solving, and may also ask questions that you never would have thought of asking yourself when you wrote the code. In fact, just having someone explain what their code does to someone else may make them realize mistakes they’ve made all by themselves. Colleagues can be excellent rubber ducks
So there you go. Four good reasons why a team should at least give code review a serious try. Do you have any reasons that I missed? Or are there arguments against code review you think are even better? Let me know!