The Dangerous Practice of Code Freezes

I am often confronted with team/companies who will announce a code freeze in order to reduce risk.  I wanted to share my views on why I believe people do this and also why I think it not only does not help mitigate risk but it actually increases risk.

What is a "Code Freeze"?

By "code freeze" I am referring to any time a code base is "frozen", or locked down from changes, in any environment to stabilize and mitigate risk.  The two most common reasons to do a this are:

1. There is an event that would cause a large number of users to be exposed to your system. Example: e-commerce site during Black Friday.
2. Before a large release to allow QA to test.

The Problem

When a code freeze is called there is a false sense that all changes are risky and risk is averted by keeping things static.  Now if that was the case, why do we change things in the 1st place.  Brought to it's most logical conclusion, if all change is risky then we should get all the possible requirements up front, deploy version 1.0 and never touch it again.  Sound familiar?
The whole idea of a code freeze the very antithesis of the values of Continuous Delivery, Continuous Integration, DevOps, Lean, and Agility itself.  Unless you are not a developer you already know that there is not one decent developer that will honor a code freeze.  That is just not how our minds work.  If there is a bug, we want to fix it; if there is a smell, we want to refactor; if there is anything to do, we will do it. Now maybe they don't commit the code, or maybe changes are sitting in a lower environment but changes will happen, they will pile up and as soon as the freeze is lifted, all those changes are released like a flood heading right toward your customers.
A similar phenomenon occurs with the backlog, sometimes even worse. We don't stop trying to learn about what we want to deliver so requirements are added, some change, and some things in the queue become less reliant and are dropped.  Aside from the obvious problem of things piling up, the biggest issue here is that all this stuff is happening without a feedback loop.  Deploying to real customers is the best way to learn. The more you deploy, the more you learn so when you do not deploy, you make bad decisions.
Most software systems are very complex.  Introducing huge change all at once to a complex system is extremely unpredictable and adding users of the system into the mix makes it even worse. (How many times have we seen users use our systems in ways we did not anticipate?)

The Solution

Change is necessary and expectations are that software teams are expected to deliver new features faster, more reliably; at the same time our systems are getting more and more complex and introducing huge change all at once to a complex system is extremely unpredictable so what can we do? We need to avoid large changes and many deliver small changes more often (continuously).  Delivering small change continuously is the best way to create stability, quality, and predictability. Following the DevOps/Lean/Modern Agile (whatever we want to call it today) of Continuous Delivery will force us to face all the issues we are trying to void with a code freeze.

• Continuous Integration into the trunk.
• Continuous/Built in Quality
• On-Demand deployments with safety bult in (canary deployments, easy rollback)
• Continuous Monitoring and Learning
• Trust in your system to catch issues early