Code Review and it’s Importance

As a developer we all write lots of code, we all try to write better code in our module and want to keep away those freaking bugs that pops up by the testers. Isn’t it? Then what is the need of doing a code review and spending those extra time for just a review process?


Whole day everyone is busy with their module, so who has the time for this unnecessary work? Is it really unnecessary? Let’s check it out in today’s blog post. I hope, you are excited to read it.


We might be working in a team located in a single building or distributed geographically. Developers write code for their individual module, test it and then check-in those code to the TFS or any other Source Control Repository. There might be an automated build server that has been configured to find out any compilation issue and then that creates a package and send it to the automated testing server on successful build.


If those are already configured like the way it should be, what is the importance of code review? It is not only the code review but a review of the whole process from the requirement analysis to deployment & testing. Everything should be properly reviewed by a peer team member or an individual to reduce the no. of defect or cost per defect.


Why we do a Review?

Code Review to Reduce Cost Per DefectA general analysis report says that, if we do review at the earlier stage, the cost to fix this will be less and thus it will reduce the overall cost of the application. It is 2400% cheaper to fix any issues in development stage than in the production environment.


The graph shows you how the review process effects the cost per defect in different stages. If you do a proper review in the requirement analysis stage and start implementing the code in proper way, you will see a less no. of defects. But if you find the defect at the later stage during or after the deployment, there will be more chances of complexity of the bugs and the cost to fix them will be very very high than resolving them in the initial state.


The same applies to code review process too. If you are working on a module, each and every part of the module needs to be reviewed by somebody to check the defects in it’s earliest stage. This could be naming convention, repetitive code block, unnecessary codes, performance measure and other minor or major defects.


Advantage of Code Review

Better code always starts with review process. It highly measures the quality of the product. As I mentioned earlier, the cost per defects highly impacts if we do a review process at the earlier stage. There are few major benefits of doing a code review:

    • We all are human beings. You may do some mistakes irrespective of your experience in a particular technology or module. If you just review your code by a second eye, those mistakes might caught at that time only. This way you can reduce the no. of bugs reported by the testers or end users.
    • If you are working in a geographically distributed team, your coding conventions may differ and if you have some strict coding guidelines, this code review process will make it possible to recheck the standards in the code that you have written.
    • There are some possibilities of repetitive code block which can be caught during a code review process. Refactoring can be done based on that.
    • Unused code blocks, performance metrics etc. are some additional check points of doing a review.
    • If you are new to development, this code review process will help you to find out your mistakes and help you to improve them. This is a perfect knowledge sharing mechanism.
    • Find out the defects and correct them at the beginning before it commits to the source control system.

There are lot more benefits of doing a code review which you will experience when you go through a code review process. If you are a reviewer or if you are the author of the code, in both the cases you will learn from the other. But in general, the author gets more chance to learn from the reviewer.


How the Code Review Process Works?

Everything has it’s own Life Cycle, the same applies to Code Review process too. A developer ones finishes the coding stuff of a particular module or task, sends that piece of code for a review to a dedicated code reviewer or a person within the team for peer review.


The reviewer pulls few minutes from the work schedule to review the code written by the other developer and provides comments to fix the issues noticed during the process. Sometime the reviewer also checks the execution of the code and provides suggestions during the review.

Code Review Process

If the review process produces any comments, the developer fixes those issues and sends requests for another set of review with the latest code. The reviewer again checks the code and provide additional comments if any with the new code. Once the process completes, the developer is ready with the code to check-in to the repository. This ensures that the quality of the code that is going to check-in to the system is good.


Problems with Code Review Process

The developer and the code reviewer

The major issues that will arise when the other member who is going to do the review of the code is not first enough. The author of the code does not have free time, he has to do lot more stuffs. So, the reviewer should be prompt enough to check the code for any defects.


But that does not mean that the reviewer should neglect piece of code to reduce the effort. This may produce a big hole. The reviewer should be smart enough to find out the defects with the code and provide informative feedback to the author of the code and the author should accept those changes and remember while writing code in future.


Another important issue with the Code Review process is, the developer throws the ball to the reviewers court without doing any self review. In some case, the developer knows that it's an issue but still wants to catch it by the reviewer. In such case, if the reviewer misses the block, it's an Golden Ball from the author of the code. He also misses the same though he knows. If something that you can check, why to wait for other to report it?


For example, look out the cartoon attached here for an interesting story. Remember, this could be a possible bug in the production and may impact your project in future. This small negligence could be dangerous in the coming days. So, make sure to review your code yourself always before sending it to reviewer for an additional check.


What’s your opinion?

As we discussed more about the review process today, I just want to know your opinion. Are you going through such process in your work? If so, what’s your real time experience with this process? Is it beneficial?


If you didn’t yet following code review process, try it at least once and see the difference. As I already said, we are human beings and hence silly mistakes can be possible knowingly or unknowingly. This review process will find out those mistakes and help you to learn from the other who just reviewed your code.


Whatever the case, let me know your thought and/or feedback if any which will help the other to understand it and also help me to improve this post. Yes, this is also part of a review process where you are the reviewer of this post and I am the author. So as expected, I will wait for the review comments, Smile right?


I am available on Twitter and Facebook where you can connect with me and say a “Hello” too. Don’t forget to subscribe to my blog’s RSS feed and email newsletter. Enjoy!!!

If you have come this far, it means that you liked what you are reading. Why not reach little more and connect with me directly on Twitter, Facebook, Google+ and LinkedIn. I would love to hear your thoughts and opinions on my articles directly.

Also, don't forget to share your views and/or feedback in the comment section below.


  1. Great Article Kunal!

  2. I second your thoughts. Indeed peer review at early stage of development & implementing fixes is far more cost effective.

    Nice article :) everyone in my team must read it :)

    1. Yes, people should start doing some peer reviews. This will help individual to learn more from the others.

  3. Replies
    1. Thanks Kirti. Let me know, if I missed any points which can improve the post for the benefits of the developers.

  4. Well done Kunal. Personally loved the professionalism in this article. Great going ... Keep these coming.

    1. Thanks a lot Vinod sir. It's my pleasure to have the feedback from a great professional and blogger like you. Let the blessings coming from you... :)

      I am eager to meet you some day in some event and get some of your advice and more blessings.


  5. One issue I find with reviews is that you need at least one highly skilled person in the review. A group of people who don't have a good grasp of the language, syntax, business domain, etc. just won't see problems.

    1. Yes, that is true but gradually the whole team should learn these things.

  6. Most of these talking points are also used when debating unit testing of the code prior to sending it to QA. Making changes to code that has a unit test available for the class would be a great way to know you didnt break the code when maintaining it. That way you can quickly know if you broke it and it might make the code review go quicker since you would know going into it that your code was working.

    1. 100% True. Unit testcases makes the code solid and thus makes sure that the existing functionality is not breaking by someone while working on that module.

      Generally developers try to skip it as it needs a lot of extra code (n times more than the actual code) but yes, the unit cases should be written.

  7. Kunal really good article. I want to share some of my practical experience here :

    Basically the problem for code review process is people or your peers in your team sometime do not have enough time to review your code. They are busy with their delivery. So, it's the organizations philosophy to make the developer feel that not only delivering code is primary responsibility of a coder but they need to review codes of their peers. And that is also part of the development responsibility.

    In my previous organisation they have certain quality metrics like TL 9000 and all. There are few QA ( Quality Professional ) who look for code check ins which are not thoroughly reviewed before submission in the code database. Now there are some costly tools available which can take the pain of QA and management for this code review.

    Say for example I worked in Linux development and the version management was ClearCase. A tool for code review is integrated along with Clearcase, that was Aquarium. All the reviewer login to Aquarium and review the code. Once they give a green in aquarium, then only can the Author checkin the code through Clearcase. So, in future if a code messed up, you can not blame the Author, you can also make the reviewer responsible who put the green flag in the Aquarium tool. So, making people responsible for code review can make life easier but then all these tools comes with a fair amount of cost.

    1. Hello Samrat,

      Thanks for the feedback. Yes, you are right. Team should estimate their tasks properly so that, they can give some time for the review process. Generally it is double of the actual time spent.

      For example, if the review process takes 15 minutes, it's actually 30 minutes spent (15 mints for reviewer and 15 mints for the author/developer of the code)

  8. I think a lot of people are looking for such a content from you. hope you will have more share such like that.- street view


© 2008-2018 Kunal-Chowdhury.com | Designed by Kunal Chowdhury
Back to top