As the business world pivots to meet the new demands and challenges of COVID-19, so too has the retail world reimagined its biggest shopping season of the year. Instead of enticing shoppers to cram the stores on one or two special days for deals and discounts, holiday shopping has engulfed the season with deals spread across weeks and even months.

With these trends accelerating the e-commerce takeover of the holiday season, you might assume this is a busy time of year for many developers. In reality, the holiday season is typically a less hectic period for developers as they stop deploying new code and instead wait out code freezes. Code freezes are a traditional practice to ensure site and app stability during high-traffic periods. They’ve been popular especially in e-commerce because of a fear that a change introduced now could jeopardize their revenue.

The downside of code freezes
Developers keep writing code during a code freeze, but instead of integrating or testing it with the main branch, the code sits and waits for the freeze to end. This means the longer the freeze lasts, the more code builds up, which introduces unnecessary risks and instabilities and ultimately slows down integrations following the freeze.

Code freezes also create a problematic scenario, often called “racing the train.” Developers attempt to “race the train” when they know a code freeze is on the horizon, but they’re on a deadline to release new code before the freeze goes into effect. To beat the train, developers might cut corners, do fewer tests, skip manual testing, or simply deliver a lower quality product because they were rushing to meet a deadline, which opens up a greater possibility that the code has a bug. However, like the tradition of waiting outside Walmart at 4 a.m. on Black Friday, code freezes may soon become a thing of the past.

The alternative to code freezes
With feature flags, development teams no longer need to rely on code freezes during high volume times. Feature flags can deploy new code to production in a “turned off” state, allowing teams to gradually ramp up or down the new code for specific user populations without a new deployment. Now, developers have the freedom to continue innovating and testing in production without worrying about how it may affect customers.

Most feature flags are enabled with a toggle, which gives teams the control to turn off a feature quickly with the click of a button at any time, including during peak traffic time. During the holiday season, this could be used to turn off new code for inventory checks or calls to non-essential third-party systems during the first few hours of a flash sale. Unlike server or service-level configurations, feature flags can be used to target specific user groups or sessions. This allows development teams to set ops-toggles to “off” for general users and “on” for premium customers, ensuring only the latter group receives the more computationally intensive options.

Traditional monitoring practices can fail to deliver accurate results when some users see a feature but others do not. Additionally, feature flags provide an in-depth look at system health and user behavior, making it clear which feature flag is causing an issue and which one is providing the best user experience. For these reasons, retailers should use feature flags to drive monitoring and experimentation practices, especially during the high traffic of the holiday season.

Feature flags, now and forever
Feature flags are the perfect tool to keep development teams running smoothly during high volume and sensitive times. However, that doesn’t mean feature flags should be stashed away for special occasions. Even something as ordinary as writing code should be done in a feature flag to mitigate risk and to have an emergency kill switch available if the feature starts causing serious issues. By incorporating feature flags into everyday practices, your team will promote a strong engineering culture that lasts longer than any holiday sale.