Code Review - Just Do It! (Part 2 - What's in it for me??)

In my previous post, I talked about code-review as one of the great mechanisms we have to provide and accept feedback during our coding-process. In this post I'll try to talk about what you will really gain by code-reviewing.

Code Review (ha!) What is it good for?? (Absolutely something!)

When I try to convince people they should apply and use code-review, I tend to encounter lots of excuses. Well, perhaps it would be too accusing to say excuses, so let's say "concerns". Before addressing the various excuses (I mean, concerns) for not applying code-review as part of the development cycle, let's try and figure out why you should do code-review and what you gain from it. In my next post, I'll talk about the different excuses for refraining from it.

Defect types 

Let's try and understand what are the common defect-types code-review can reveal; In a research conducted in the University of Helsinki ("Defect Detection Efficiency: Test Case Based vs. Exploratory Testing") they tried to identify the types of issues found in a review. We can group those issues into three groups:

1. Functional - The code doesn't do what it supposed to
2. Maintainability - The code structure would be hard to maintain (classes that do too much, code style, strong coupling and so on...)
3. False positives

While one might think that the functional problems are the main problems found in a code review, turns out these problems comprise only 21% of the problems found in a review. It means that usually, when you reviewing code, the code actually works exactly how the author claims it works. The majority of the problems are the maintainability problems which comprise 71% of the problems. This means that by code-reviewing you help keeping your code clean, maintainable and defend it from rotting. 

Defect Reduction

I tried to the dig around the web for numbers of defect reduction for different methods. I wasn't able to find any concrete scientific numbers, but I did find some less-official estimations. But between pair-programming (15%-50% of defect reduction), unit-tests (30%-60%) and code-review meeting (45%-50%) - I found the method I like most, the asynchronous code-review (in which you send the diff of your changes to your peers and they respond on their own time), to be considered as the most affective one with 60%-65% of defect reduction.

Still not sure?

Even when the numbers are so solid, people often can't see what they can gain, personally, from code-reviewing. Let's take a moment to talk about that.

Why should I seek this feedback?

Better code inspection

Before I publish my changes to review, I usually take a few minutes and read it again. Ensure I haven't left out any commented code or tweaks I had done while working, making sure the variables and methods are named with readable names, and so on. I do it because I know people will dig through my code, and I don't want to embarrass myself with poor quality code. This alone, helps me find issues even before the actual code review.

Get feedback from unbiased eyes

Your code does not necessarily do what you think it does. It's also not as readable as you might expect it to be. Having someone that was not part of the code-writing, inspecting your code, reveals the true readability, and true purpose of your code.

Find your problems sooner than later

I've already met a lot of people that prefer ignoring their problems. And why won't they? You're about to finish a feature you have been working on for a few days, you can't wait for it to be committed and deployed, and now you're getting all sorts of feedbacks and comments that require you to make changes to this state-of-the-art piece of code. But the fact is that the problems aren't going anywhere. You should embrace feedback and fix your problems as soon as you find them, while your mind is still on this mission. Fixing it later will cost you more as you will try to remember and understand the things you did, and why you did them.

You'll commit and deploy your code, don't worry. You'll be even more proud of it after you have fixed the issues.

Learn new stuff

You'd be surprised about what your peers can teach you. From a simple review you can learn about design patterns, quality-patterns, performance issues, design issues and a whole lot of other stuff. Try to learn from your peers, it's important in our line of work.

Teach the others

And your peers can also learn a lot from you, if you just give them the chance. By conducting code-review, they get a chance to see how you do stuff. And they'll most probably love to learn from you.

Why should I provide feedback to others?

Improve code-reading skills

One of the most important skills for a programmer is the ability to read other people's code. Practice code-review and you'll see how it allows you to get into new-code in no-time.

Learn new stuff

I already mentioned it in the previous section. This is your chance to learn how your peers work. Learn from it!

Better understanding of the code

By consistently reviewing your peers work, you'll learn what happens outside your zone. You'll get a complete view of the system you're working on, which will allow you to understand the affect of your code on all of the system.

Common goal

People tend to forget it. Your peer's success, is your organization's success which means your success! Help your peers improve their work, and your organization will become more successful, which you can only benefit from.

Let your voice be heard

How many times have you looked into others code and thought to yourself "what the hell they were thinking"? This is your time to prevent it! Let people know how you think things should be done. Not always will it work, but when it will, the future reader of the code (which might be you) will thank you for not letting things deteriorate.

What about the organization?

Organizations that encourage code-review will benefit greatly from the process. By creating more capable employees (which learn new-stuff all the time and improve their code-reading skills), by having a process the encourages knowledge-sharing. Also, new employees won't clutter the code due to their lack of understanding on how things work in the organization. The quality of the product will increase - allowing faster development of new feature and less bugs that the customers will have to face.

Lastly, code-review encourages discussion. An organization that wants to move forward should allow discussions and criticizing the process. Discussion is one of the most fruitful ways of taking the organization forward.

Hope I convinced you a bit more about code-review. In the next post I will cover the excuses I tend to hear as to why not to perform code-review. Stay tuned....

Find me on Twitter: @AviEtzioni

More interesting posts from this blog: