In a 2016 letter to Amazon shareholders, Jeff Bezos famously said “it is always Day 1.” (emphasis in original). He describes the “Day 1” mentality as having a strong customer obsession, a skeptical view of proxies, the eager adoption of external trends, and high-velocity decision-making. He has more detail in the full letter, and it is well worth reading (or re-reading).
The part that really caught my attention was his contrasting description of what “Day 2” looks like:
Day 2 is stasis. Followed by irrelevance. Followed by excruciating, painful decline. Followed by death. And that is why it is always Day 1 [at Amazon].
He then goes deeper into explaining some of the manifestations of an organization that is slipping into Day 2. One of these points is how to maintain velocity - to move quickly - and how this is “[e]asy for start-ups and very challenging for large organizations.” One of those manifestations of Day 2 thinking is a Code Freeze.
A code freeze is “a point in time in the development process after which the rules for making changes to the source code or related resources becomes more strict.”1 It can range from halting changes in particular areas or layers to a full stop of all changes to the source code.
A code freeze says: “We will not improve the product for a period of time”, “What we have is good enough for now”, and “We should pump the brakes”. This goes directly against something else that Bezos says in the same paper. “[C]ustomers want something better, and your desire to delight customers will drive you to invent on their behalf.” A code freeze halts invention. It delays customer delight. It shouts slow down! and whispers something better can wait.
A code freeze is a misguided attempt to halt change itself. I’ve witnessed code freezes at multiple organizations (including one founded by Mr. Bezos) and, despite the differences between them, the code freeze always had a negative impact on technological innovation, velocity, and improvement. This loss is supposed to be offset by a risk-mitigating stability in the system during a “peak” selling season.
But, aren’t your engineering teams constantly mitigating risk? Is that not a key part of their work? Why choose one week (or month) out of the year to say “you guys aren’t doing your job” instead of addressing this throughout the year? There is a strong, barely-hidden message to your development teams here, and it is not pleasant.
Once a code freeze is accepted for, say, the Christmas shopping season, it becomes easier to propose (and adopt) something like “we should also code freeze for our major summer Rhyme Day event.” As this spiral slides downward, existing Continuous Delivery processes are made less “continuous”, automatic tests are no longer fully trusted, and software engineers are viewed not as “the source of customer delight” but as “the source of customer angst - we must stop them!”
The consequences of willingly dipping your toe into Day 2 are real. Bezos doesn’t mention choosing to go to Day 2, he speaks of defaulting on Day 1. He implies a certain gravity that acts on complacent organizations, moving them away from delightful innovation and toward the stasis of constancy. I believe this gravity is real and Bezos is right to identify and fight it.
I advocate for more continuousness, not less. If your process needs better quality, do the work to bake it in. Work with your engineering teams to own their quality and constantly improve it. Deliver fast. Now, deliver even faster. Have high standards year-round. Build trust. All of these are characteristics of a Day One organization.
It takes purposeful effort to remain at Day One. If you let up, complacency has a chance to creep in and calcify your company. A code freeze should be recognized for what it is - an abdication of your dedication to Day One principles.
https://en.wikipedia.org/wiki/Freeze_(software_engineering)