The Unexpected Code-freeze Algorithm
Temporary Code Freezes are a widespread practice in tech, when all deployments are stopped for a few days before some important Big Event passes.
The goal of a Code Freeze is to reduce uncertainty introduced by changes by, well, preventing the changes.
The problem with announced code freezes is that it often leads to stampedes: developers are rushing to push their code out before the Code Freeze, corners get cut, vetting quality plummets, etc.
Often, “the last deployment train before the freeze” is a bit of a cluster, with too many changes, poorly tested, resulting in higher-than-usual rate of regression and uncertainty, which kind of defeats the whole purpose.
The “ideal” solution is not to have the code freezes at all, but that requires the levels of technological maturity that take lots of time and effort to achieve, particularly in hyper-growth companies.
We propose a pragmatic solution: “The Unexpected Code-freeze”:
Announce two weeks in advance that on a random day between Monday and Thursday, at noon, there will be a suddenly announced Code Freeze.
(The exact randomization scheme is left as an exercise for the reader)
That’s it, no stampede. Those who wait for the last minute to ship their changes will either have to plan to ship in advance, or will have to wait until after the Big Event.
Happy deployments!
P.S. This post is inspired by the Unexpected Hanging Paradox.
