About Petri Kainulainen

Petri is passionate about software development and continuous improvement. He is specialized in software development with the Spring Framework and is the author of Spring Data book.

Code Reviews with Five Whys

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.
 

Reference: Code Reviews with Five Whys from our JCG partner Petri Kainulainen at the Petri Kainulainen blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

One Response to "Code Reviews with Five Whys"

  1. An0nym0usC0ward says:

    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 a tool (I mean, like reviewboard or gerrit) is that it makes the review process more flexible. Instead of either having to do pair programming (which not many people/companies like/use), or doing code review on the entire code base once in a while on frozen code, or having both the coder and the reviewer(s) waste time in front of the same screen, or even do code review on individual sets of changes post-commit (which is IMO pointless), you get to decouple the coding process from the review process.

    You have to take care not to transform this into a nazi process, though, where you absolutely have to do what the reviewer(s) say. This can be extremely counterproductive, especially when you have designated reviewers, which don’t do much else – in this setup reviewers tend to become sort of a furniture police.

    It also helps if you use tools like checkstyle and findbugs (if you live in Java land – I don’t know how good their support for other languages is, or what tools of the same type exist for other languages). This way, you get to fix lots of details even before you get to send something out for review.

Leave a Reply


nine + = 13



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close