Code Freezes and Feature Flags

Code freezes in Q4

As Q4 quickly approaches, your team may be having the code freeze conversation soon.

While there are lots of things to consider when implementing a code freeze, we’re here to help you make the best decision for your team. This article will cover the why’s, the pros and cons, and how feature flags make your life easier if you decide to freeze your code this holiday season. 

What’s a code freeze?

A code freeze is a mutual agreement among your developers to stop making code changes or pushing new code for any given amount of time. They’re common during the holiday season, especially for sites or digital platforms that see an increased amount of traffic in Q4 – (i.e. online retailers, eCommerce sites, etc). Code freezes provide some additional assurance that nothing goes awry with these platforms during the busiest months of the year. 

Let’s say, for example, that Best Buy decided to make some code changes that caused a major bug on December 15th. They probably see high traffic on that day with folks doing last minute holiday shopping. Thus, that code change + bug + downtime might cost them triple or quadruple the business that some downtime might cost them on, say, July 15th. Best Buy might consider implementing an internal code freeze from November onwards to ensure that they remain optimal and running for the holiday season.

But code freezes aren’t just for online retailers. They’re helpful for any dev team that has a 24/7 running product but would like to take some (well deserved) vacation time during the holidays. If your developers plan to take a week or two off at any time towards the end of Q4, you’ll likely be operating at reduced capacity. If this is the case, you might be left with just 2 or 3 developers that can fix a bug if code changes are made in the days or weeks leading up to the holiday season. Even then, those 2-3 developers probably requested a few days off at some point during the holiday break, and they deserve to take their respective time, too.

A code freeze would let your devs rest assured that when they take time off, they can actually  relax knowing that no major code changes (and thus, no major bugs) will arise during their vacations.

Not to mention your support team also benefits from a code freeze. Even though they might be tasked with answering a few questions during the holiday season from new or existing customers, a code freeze and halt on new releases means it’s likely that they’d only get questions they already know the answer to. Similarly, they won’t be fielding complaints surrounding bugs or that a newly released feature isn’t working properly. 

To recap: code freezes are generally a good move for teams running a 24/7 platform that see high or sustained traffic during Q4. 

The top three reasons to implement a code freeze:

1. You’re likely operating at reduced capacity/fewer devs at some point during Q4.

2. Code freezes reduce your chance of bugs and downtime: being down during the holidays is much more expensive than being down during the summer for a lot of companies. 

3. Give your staff a real holiday. Your devs should be able to take time off without worrying that they have to stay close to a computer should something go awry. Give them some assurance that your platform will remain status quo for a few days while they enjoy their time off. 

While we think code freezes are generally a good thing to implement if you’re facing any of the above scenarios, it’s time to consider what might happen if a code freeze goes wrong. 

That’s where feature flags come in

A code freeze + feature flags is a winning combination that leads to a truly stress free holiday season. Here’s why:

Using feature flags on your applications during a code freeze would allow you to turn something off if there's a bug without breaking the code freeze or having to release more new code that might also have a bug. 

This is key if you have a smaller team working over the holidays. Rather than expect one or two of your devs to spend December 24th fixing a bug and releasing new code, someone can simply log on to your feature flag console, turn “off” the feature that has a bug, and users will revert back to a default, working UI until your team returns from break.

Here's what to consider:

We hope this article serves as a useful resource for you and your team as you navigate the code freeze conversation in the coming months. We’ll close by leaving you with a few questions we think every dev team should ask themselves before making the decision to freeze their code: 

1. What are the pros and cons to implementing a code freeze this Q4?

2. If we do implement one, who is responsible for making the call?

3. Who can override that call if a change to code is necessary during the freeze?

4. When would the code freeze start and end? Would there be multiple throughout Q4, or just a continuous freeze from one date onwards?

The results

Like any other business initiative, we also recommend outlining some ideal results (i.e. what your team wants to achieve by implementing a code freeze) so that you have some idea of whether or not it was the best choice for your team in the long run. 

Ultimately, code freezes + feature flags are the best way to ensure minimum downtime and an optimal product this holiday season. If you’re thinking about implementing a code freeze in the coming months, now is the time to introduce feature flags into your workflow. You can check them out here, and start using feature flags today with our 14 day free trial.