Are code freezes ever a good idea?

I found a tool to make code freezes easier. Ick. But could it ever be useful?

I recently learned of a GitHub app to facilitate code freezes, and it even supports scheduled code freezes.

Despite my immediate reaction of…


…it got me thinking: Is there ever a valid case for a code freeze?

I came up with two, partly overlapping, answers.

  1. A code freeze is a useful emergency tool.

    If your software delivery pipeline is not yet mature enough to deliver stable software consistently, then a code freeze can at times be the only short-term solution. But this is a bit like calling the fire department to your Independence Day BBQ preimptively. The better solution is early prevention. Treat every code freeze as a learning opportunity to improve your software delivery process, so that future code freezes won’t be necessary.

  2. Slow review processes.

    In some truly rare situations, we may be required to let our code go through some sort of long, drawn-out review process before it can go live. The usual requirement is that the code under review can’t change. Fortunately, this practically never actually requires a code freeze. At most, it requires a git tag. And it may require a release branch made from that git tag, if cherry-picked fixes are required there.

    But there’s no reason to freeze the whole project!

    Even the Debian Linux distribution, notorious for slow releases, and long code freezes, doesn’t freeze the whole project. They take a snapshot of their development work (the testing repo), and work on stabilizing that. Meanwhile, work continues as usual on their testing.

    But in reality, this is just a subset of the first case. A code freeze is a response to a sub-optimal situation (slow review). It would still be good to take this as a learning opportunity to reduce the duration and frequency of code freezes.

Share this