{"id":784,"date":"2019-04-06T19:36:01","date_gmt":"2019-04-06T18:36:01","guid":{"rendered":"https:\/\/www.michaelagreiler.com\/?p=784"},"modified":"2023-01-08T14:18:09","modified_gmt":"2023-01-08T13:18:09","slug":"code-review-pitfalls-slow-down","status":"publish","type":"post","link":"https:\/\/www.michaelagreiler.com\/code-review-pitfalls-slow-down\/","title":{"rendered":"Code review challenges that slow down your productivity"},"content":{"rendered":"\n
\"\"
Code review pitfalls can decrease your teams’ productivity
Photo by Sebastian Herrmann<\/a> on Unsplash<\/a> <\/figcaption><\/figure>\n\n\n\n

Many teams face challenges when conducting code reviews. In this article, we will look at the most common and most problematic code review challenges and also outline how to overcome those. <\/p>\n\n\n\n

<\/p>\n\n\n\n

Code review is an engineering practice used by many high-performing teams. And even though this software practice has many advantages, teams regularly face problems doing code reviews that slow down software development. <\/p>\n\n\n\n

Knowing which problems arise during code review can help you to ensure a productive and effective code review experience. The code review challenges presented in this article are based on a survey we conducted at Microsoft with over 900 participants<\/a> and on my years-long experience giving code review workshops<\/a>.<\/p>\n\n\n\n

A typical code review process <\/strong><\/h2>\n\n\n\n

A typical tool-based code review process looks roughly like this: <\/p>\n\n\n\n

Once a developer has finished a piece of code, she prepares the code for being submitted for review. Then, she selects reviewers who should review this code change. The reviewers then inspect the code and give feedback. The author of the code looks through the feedback and improves and changes the code if need be. Once everybody is satisfied, or an agreement is reached, the code can be checked into the common code base.
In another post, I described what a typical code review process looks like at Microsoft.<\/a> And here, I describe how Google reviews code<\/a>.<\/p>\n\n\n\n

<\/div>\n\n\n\n
\n
\n

For my e-mail subscribers, I prepared an exclusive code review e-book, including a checklist with all code review best practices. I also added additional bonus insights. You can request the Code Review e-Book here<\/a>. <\/p>\n<\/div>\n\n\n\n

\n
\"\"
Check out the VIP Code Review e-Book<\/a> I prepared for my subscribers. <\/figcaption><\/figure>\n\n\n\n

<\/p>\n<\/div>\n<\/div>\n\n\n\n

Code reviewing isn’t always a smooth process<\/h2>\n\n\n\n

These steps read like a smooth process. But, like everything, things are more complicated than expected. There are quite a few code review challenges that can reduce the positive experience with code reviews for the entire team and take a toll on the team’s productivity. So, let\u2019s have a look at the difficulties and challenges of code reviews.<\/p>\n\n\n\n

The biggest code review pitfalls are about the time spent on code reviews<\/em> and the value code reviews provide<\/em>. <\/p>\n\n\nCode reviews are only effective, valuable and fun, if you receive feedback in a timely manner. <\/a><\/span>Click To Tweet<\/a><\/span>\n\n\n

<\/p>\n\n\n\n

Waiting for code review feedback<\/h2>\n\n\n\n

One of the most frustrating problems during code reviews is waiting for code review feedback. Code reviews are only fun, effective, and valuable if you receive feedback in a timely manner. Waiting for the code review feedback to come in means that you are not able to work on the code in the meanwhile. So you either spend your time scrolling through Twitter, or you have to do a context switch and work on another task. Both can be a huge problem. Even though developers can pick up other tasks to work on, if the code review takes too long, it impacts the developer\u2019s productivity and also the developer\u2019s satisfaction. <\/p>\n\n\n\n

But why does the code review feedback take so long?<\/p>\n\n\n\n

Code reviews are a “necessary evil”<\/h2>\n\n\n\n

Code review is not the only task the developers have to perform. Even worse, in most companies and teams, developers’ main task is to write code, not to review code. This means that code review has a lower priority to developers than working on features. Depending on the incentives and how different tasks are valued in a team, code review might come even behind writing tests or attending meetings. In fact, at several companies, code reviews are seen as a “necessary evil”. <\/p>\n\n\n\n

In addition, code review can take a significant amount of time in a developer\u2019s day-to-day work. So, it is likely that the code reviewer is engaged in other activities and has to stop or finish those first before looking at the code review. <\/p>\n\n\n\n

If the timing is not ideal, and especially if the code reviewer hasn\u2019t expected this change to come along, chances are it will take a while before she looks at the review. Remote teams also have to be aware of time zone differences. Otherwise, code reviews might even take longer.<\/p>\n\n\n\n

Code reviews are not counted as actual work<\/h2>\n\n\n\n

Time constraints are real, and they affect both the code reviewer and the author of the code. Doing a proper code review takes time. If teams want developers to do code reviews but do not value or count the time developers spend on code reviews, this becomes a real problem.<\/p>\n\n\n\n

\"clock
You have to value and plan for the time spent doing code reviews.
Photo by freestocks.org<\/a> on Unsplash<\/a> <\/figcaption><\/figure>\n\n\nYou can't expect quality code reviews if you don't value the time a developer spends on them. <\/a><\/span>Click To Tweet<\/a><\/span>\n\n\n

Not rewarding code review activities<\/h2>\n\n\n\n

It does not help to claim to value code reviews if you do not reward the effort developers spend on this task. Many companies focus on rewarding developers for the amount of code they write or the features they develop. This decreases the motivation and the ability of developers to do a good job helping each other (which includes code reviewing). Code review performance should be a cornerstone for performance evaluation or promotion decisions.<\/p>\n\n\nIf you want your team to do code reviews well, reward them for their work. <\/a><\/span>Click To Tweet<\/a><\/span>\n\n\n

Missing guidelines on code reviews<\/h2>\n\n\n\n

Another code review challenge is missing guidelines or training on how to do code reviews. If developers have no clear idea of what is expected from them during a code review, they also might procrastinate on doing code reviews. This increases the time spends waiting on review feedback. In addition, it reduces the value of the feedback because developers have no clear instructions on what to look for. Training on code reviews<\/a>, which creates a shared understanding of the goals of code reviews, and how to do them, helps to overcome this challenge. In addition, teams can use code review checklists<\/a> to guide developers through code reviews and make code review more systematic and effective. <\/p>\n\n\n\n

\n

I’m expected to participate, but I’m not quite sure how. I’ll wait until someone else starts.<\/p>\n(study participant)<\/cite><\/blockquote>\n\n\n\n

Large reviews are hard to review<\/h2>\n\n\n\n

Large code changes, that span several files and consist of more than 400 lines of code create another significant code review challenge. Imagine you are the reviewer, and you just got a code review request. You think: “I am quickly going to look at that”. But once you open the review, you see this large code change. Several files have been changed, and all changes tangle throughout the code base. What’s your first reaction?<\/p>\n\n\n\n

Probably: holy cow!<\/p>\n\n\n\n

That\u2019s right. That is exactly what we saw when analyzing thousands of code reviews. Not only does review time increase with the size of the code change, but also feedback quality decreases. Well, that\u2019s probably understandable. <\/p>\n\n\n\n

10 lines of code = 10 issues.

500 lines of code = “looks fine.”

Code reviews.<\/p>\u2014 I Am Devloper (@iamdevloper) November 5, 2013<\/a><\/blockquote>