Code Reviews During Emergencies

It’s 3:40pm on a fine Friday afternoon. You are about to wrap up the main logic for a feature you’ve been working on for a couple of days when you notice you have unread Slack notifications. One catches your eye in particular:

“Hey! Emergency. Need approval on my PR. I have tested everything on dev so if you can quickly approve, I can merge it before the weekend.”

Emergency. Alright, they have your attention. You could stop what you are doing and do a superficial code review on their pull request (PR) because after all, it’s an emergency. But you are curious and fire back seeking to understand the context:

“Sure, I can take a look right now. What’s the emergency? Is it a bug in production or does the legal team want something updated ASAP?”

They reply back right away:

“No, I want to merge this code that does <insert something innocuous> because I’m OOO on Monday and want to get this released today”

Urgent? Perhaps. But does this constitute an emergency? Definitely not.

In this post, we’ll discuss how to review code during emergencies. Let’s first begin by establishing an understanding of what constitutes a real emergency.

Emergencies

An emergency is a critical bug in production that’s affecting users, a major security issue, an urgent legal concern or something that’s blocking a major feature release that has a significant impact on KPIs.

I think it’s easier to understand if we look at a few examples of what is not an emergency:

Not Emergencies

The following examples are not emergencies.

• The author has been working very hard and long hours on the feature and wants to get it out ASAP.
• It’s 30-minutes to the weekend code-freeze deadline so it’ll be nice to get it merged.
• The author’s manager told them that it’d be great if they can release the feature this week.
• The author will be away for the next couple of days.

These could relate to urgent situations or special circumstances that could definitely be important. Delaying a release may not be ideal, but it’s not usually catastrophic, hence not an emergency. (The only exceptions are feature releases where something bad would happen if it were to get delayed.)

Code Review Protocol During Emergencies

You might ask yourself that if it’s so important to fix the bug during emergencies as soon as possible, should we even bother with code reviews? The answer is that yes, you should definitely review all changes, including during emergencies. However, during emergencies, we should adapt our code review process and make some changes to it.

Emergencies require special attention and a modified code review process. For example, during normal code reviews, you might look at various aspects such as complexity, style, code documentation, unit tests, etc. and provide suggestions or nitpick. However, that won’t work during emergencies, where the goal is to complete the code review process as fast as possible.

Here are four things code review authors and reviewers should do differently during emergencies:

1. PR Authors: Keep the Change Small and Focused

The authors of the PR should make sure that it is a small change going out to specifically address the emergency only. Do not add anything extra that could confuse reviewers and introduce potential delays. Keep your change small and focused.

2. Reviewers: Complete Review as Fast as Possible

While normal code reviews can take anywhere from a few hours to a few days to complete, during emergencies it is critical that code reviews are completed as fast as possible. Speed is the main priority and takes precedence over everything else. Just like the author of the PR dropped everything to get the fix out, the reviewers should do the same and make code review their top priority.

3. Reviewers: Limit Code Review Focus

During the normal code review process, a reviewer may look at various aspects of the code such as its design, complexity, code style, to name a few. However, during emergencies, the reviewers should limit and restrict their focus to one and one thing only: “does this address and resolve the emergency?” In other words, the main criteria is that if we merge this code into production, will it make the bug go away? Refrain for providing suggestions or opinions as they’d have no impact on the PR’s ability to address the issue. I’ll repeat myself here: speedy code review is your top priority here.

4. Everyone: Follow-up With More Through Code Review

Once the change has been released to production and the emergency has been resolved, and you have all taken a deep breath and relaxed, it’s time to revisit and do the regular or more thorough code review. Do not skip this step if reviewers noticed things during ‘emergency code review’ that you didn’t call out due to urgency at the time. For example, you may have noticed that the code was poorly structured and too complex to be understood in the future and maintained. Call it now so the author can follow up with another PR to address these issues.

Summary

In this post, we looked at how to do code reviews during emergencies such as handling critical bugs in production. In emergency situations, we should not skip the code review process, but rather adapt it to focus on the speed of completing the review, keeping the code review focused on the code’s ability to address the issue and then following up with a more formal code review process.

I would love to hear your feedback, comments, and thoughts. Please leave a comment below sharing your experience or anything that would add value to this article and its future readers.