We are told that we should organize code reviews because code reviews good for our code base. We have followed this advice and managed to build a magnificent facade. We are doing code reviews and improving our code base. Everything is looking great from the outside and it might be true that we are making some progress.
However, we are not unleashing the full potential of code reviews yet.
Code Reviews Are a Waste of Time
The traditional code reviews have two major problems:
- The code base is too big. Because a traditional review is typically organized before or after a milestone, the reviewed code base is so big than nobody can read it through in a reasonable amount of time. Also, if we are honest, we have to admit that no one wants to spend a lot of time for reading through large chunks of code even if one would be allowed to so (and this not often the case). This is why the majority of comments are pretty much worthless.
- The feedback is always late. When a code review is not a continuous process that is integrated into our day to day work, a lot of code has been written before the code base is reviewed. In other words, if we find something critical from the code, the odds are that the same mistake is made more than once. We are screwed. We have critical problems in our code base and often we are not given enough time to fix them.
Traditional code reviews are a waste of time. It makes absolutely no sense to drag the whole team in a meeting room to discuss about review notes that are both late and useless. It would be much more productive to let us improve our code base instead of dragging us into a meeting which sole purpose is to give an impression that we care about the quality of our code.
Luckily for us, all hope is not lost.
Form Follows Function
There is a saying which says that road to hell is paved with good intentions. The intention behind the traditional code reviews is good but the execution causes more problems than it solves. Instead of leaning on burdensome processes, we should aim to make the code review a part of our every day work.
We can use pair programming and review the contents of each commit. These techniques solve most of the problems of the traditional code review process because they offer flexibility and instant feedback that is nonexistent if we choose to follow the traditional path. However, I have been wondering if there is something else we can do.
There are two reasons why we are doing code reviews:
- We want to keep our code base clean and eliminate as much crappy code as possible.
- We want to share knowledge with your team members.
The five whys is a problem solving technique that is used to determine the root cause of a problem. Its main idea it to keep asking the question “Why” until the root cause of the problem is identified. So, what has this got to do with code reviews?
This technique helps us to identify the reason why the reviewed code is implemented the way it is. This information matters because it helps us to evaluate the current implementation against its intention. This helps us to concentrate on the function of the code instead of its form. To make things clear: form matters but it follows function; not the other way around.
As a bonus, we are spreading the hidden information to the other members of our team.
From Judgement to Improvement
The idea of using the five whys technique is probably not new for an experienced software developer. It is a technique that we should already be using in our daily work. However, it has one unexpected advantage.
Traditional code reviews can be unpleasant situations which can cause unnecessary friction between our team members. Some of us have the tendency to take all feedback personally and some us are less than great at giving constructive feedback. This is not professional but it is very human.
The five whys technique is a clever way to include the software developer who implemented the reviewed code to the review process as an active participant. This reduces stress because it makes our fellow developer feel that we are trying to understand his decisions instead of just judging them.
This is a huge benefit because now we can focus on our common goal and start making continuous improvements to our code base.
Might call it the preschooler’s code review technique – children at about 3-4 years ask a lot of “why” questions. The code review process I like is not reviewing the code base itself, but reviewing commits. Using a tool like reviewboard, you upload a diff, designate one or more reviewers, and act upon their feedback before actually committing – works wonderful with git stash, since you can easily juggle several sets of changes in parallel on the same working copy. (And using git-svn, you can use the same process with a svn central repo too.) The nice thing about using… Read more »