D’Arcy has a good take about how fast you can do code reviews. As he himself says, the example is a bit contrived, but the point remains: You don’t have to spend a lot of time to do code reviews. Many mistakes can be identified within a few seconds of looking at the code. If you are at the level where you have to spend several minutes analyzing the code to identify problems, then either the code is very good or you are a very bad programmer. Hopefully, the latter is not true, so at that point, you are at the stage where code reviews are reaching a point of diminishing returns.
Doing code reviews is perhaps the fastest method for improving quality in a team. It allows knowledge and experience from the senior members of the team to flow to the junior members, thus enabling them to improve their coding standards quickly. When a team starts doing code reviews, they can easily identify and get rid of the low-hanging fruit in code quality. This, in turn, provides greater stability to the product allowing the team to focus on higher-level tasks. A virtuous cycle follows where the team keeps building upon improvements in quality.
There are many reasons why people don’t do code reviews despite its advantages. One is that many organizations try to formalize code reviews, creating overhead in terms of planning, documentation and follow-up. What should be a few minutes gets planned into an hour-long session with templates to be filled and reports to be registered. Because it takes too long to do one code review, there are fewer code reviews done in total.
Another problem with formal code reviews is that it introduces hierarchy and power structures into the code review activity. Instead of one programmer providing constructive feedback to another programmer, we get metrics collection and performance evaluation. Programmers have to protect their reputation and ego and so try to avoid code reviews.
An important rule is that the more you do code reviews, the less people avoid them and vice versa. If you do a code review once a month, you will find more errors and this looks bad for the programmer. When you do frequent code reviews, you may find a couple of errors that the programmer can easily fix and it does not seem like an embarrassment. Also, the quality of code goes up with each code review (as people avoid older bugs) and they look forward to showing better quality code. The end state is that people ask for code reviews to show off their code and challenge you to find bugs.
Now, there are many tools that help you identify coding problems. My view is that it helps advanced programmers more than it does junior members. The latter need more direction and prioritization initially. Soon, they will know how to better use tools to improve their coding. Automated tools should be considered a complement to code reviews. Use them, but do not dispense with code reviews in a team setting.
An important thing to remember is that if you are doing a code review for the first time with somebody, only raise 1-2 issues so that they are more inclined to come back for more once they fix them. Comment only on the most critical problems in their code. Also keep the tone calm so that they don’t feel that they are in an inquisition. The whole idea is that they should feel that both you and them are working towards the same goal of quality in the product. It should never be about the programmer who has written the code.