WHY SOFTWARE REVIEWS ARE LIKE BROCCOLI
What is a code review?
Let us start with Wikipedia’s definition:
Code review (sometimes referred to as peer review) is a software quality assurance activity in which one or several humans check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation. At least one of the humans must not be the code’s author. The humans performing the checking, excluding the author, are called “reviewers”.
Code reviews are a practice where we look at the code that we have written and then try to improve on it. The main reasons for this can be many things, but I have narrowed it down to two things that I believe are the most important. Finding & fixing bugs and sharing knowledge. I will also give some pointer on what to think about when trying out code reviews in your team.
Code reviews save time
Usually the standard thought is that code reviews cost time and does not give nearly enough in return. That means you are not looking far enough in the future. Like broccoli, the returns are plentiful and awesome when doing it for a longer amount of time.
I mean that code reviews save time in two main ways.
- It helps fixing bugs early
- It helps increase everybody´s knowledge of the code
It helps fixing bugs early
The later you find an issue, the more it costs to fix it. The chart bellows describes that the relative cost of fixing an issue in your code increases by a factor 10 relative to fixing it when writing the code. By definition that means that you, for each hour spent writing code, can spend up to eight hours reviewing it and still come out on top if you find any issue.
That is an oversimplification of course, not all code will have serious defects that actually affects the users. However, if some of it do it will help to find it early. Code review is an excellent way of finding problems early. Simply because more eyes and minds have more points of views than one, and therefore have a greater chance of catching mistakes.
Code reviews increase code knowledge
I cannot even count the number of times I have heard something similar to this. “We can’t fix that bug right now because the developer that wrote it is sick this week.” Spoiler alert! It is a staggering amount.
What this really means is that there are certain blocks in the code that is treated like somebody’s baby. Usually it is a complex part of the software and a core feature of the system. It is tricky to just walk into this code and start fixing stuff because it might lead to unexpected results. The remedy is usually to let this be what it is and then let the developer take care of all the bugs and all the improvements in that code because they are best suited to fix it. After all, they are the one who wrote it and knows everything about it.
It does not take too much to figure out that this is an unsound strategy. Usually the developer could work on other parts of the system but isn’t because they are bogged down with fixing old code.
What happens if they leave the project? Go on parental leave? Worse, leave the company because they only get to work on fixing ten-year-old code? As responsible for software development, it is not only your responsibility to fix the code now. It is to ensure that the code is good tomorrow and next year.
Code reviews help with this because it gives more developers insight into different parts of the code. With time and effort spent on code reviews, the collective knowledge of the code is increased. That means that when an issue happens (and it will) you have an entire team ready to work on it. That means better response to change and better distribution of the work. Therefore, it saves time for your all-star developers.
To summarize, not doing code reviews is actually a cost. A cost that you can minimize by starting to do them. Like broccoli, the effects are not obvious immediately and it is hard to draw a straight line between cause and effect. However, if you want to get a better chance of delivering an awesome experience both for your customers and for your developers then you get going right away.