My Opinion on Code Freeze

Taking advantage of the fact that it's already the holiday season, let's talk about a topic that many of us have dealt with at companies around this time: code freeze.

1 - What is code freeze?

In the world of software development, we call code freeze the practice of not deploying changes to production for a period of time, which usually coincides with specific periods like the holidays, or if you have an annual event, such as Black Friday week, when you have much higher traffic than usual.

1.1 - Why do a code freeze?

The theory says that doing a code freeze minimizes the risk of breaking your app during this period, and up to a point that’s correct. If you don’t deploy anything, nothing can break because of new changes. But the main reason is to avoid incidents when most people are on vacation, so there are fewer eyes and hands available to fix any problem if it happens.

This makes a lot of sense in monolithic systems, especially in large companies where all teams touch everyone’s code, and it’s relatively common for a change to go live and then three or four days later another team realizes that something has broken for them.

But leaving aside these kinds of companies/apps and the events that happen once a year, does code freeze really make sense?

2 - The Reality of Code Freeze

Even though what was mentioned in the previous point may or may not make sense, the reality is that code freeze harms more than it helps. Yes, there are specific cases where it can help. But what about all those companies that don’t have a monolithic system, but work with microservices, or where nobody goes on vacation at Christmas? What’s the point in blocking deployments? I’ll tell you: none, zero, it doesn’t make sense.

Unfortunately, this isn’t the only issue we’ll discuss today. Code freeze happens, and everyone knows it will happen and for how long. This brings two problems:

In the weeks leading up to the code freeze, everyone rushes to deploy things, no matter how small the change is, it needs to go live before code freeze. This means many features go to production without being properly tested.

The last two weeks before code freeze become a race to deploy as many changes as possible, with or without proper testing. If no one complains, it gets forgotten about by year-end.

Then comes the other side, the end of code freeze. At this point, it’s usually the end of the holiday period, which means you have about 3 or 4 weeks’ worth of changes and features to deploy to production as soon as possible. And just like before, now you have loads of changes that need to be tested in production.

Normally, things go fine, apart from QA or whoever does the testing having the two/three worst weeks of their lives. But if something goes wrong, it could be a change made three weeks ago , and who remembers that by now?

Also, in many cases, client companies go on holiday too, so if you release something with a bug, the affected user base is much smaller than the rest of the year.

Conclusion

As you might have guessed from the text, my opinion on code freeze, except for rare exceptions, is that it does more harm than good.

Companies boast about CI/CD and then don’t deploy for a month to avoid breaking things. Every person and team should be responsible for what they do. If your whole team is going on holiday tomorrow, then don’t deploy today. But if someone’s staying, then what’s the issue?

Of course, if you want to deploy during code freeze, you can, but it’s usually an emergency: managers get involved, you have to justify the reason, and so on. I’ve seen with my own eyes a bug (a minor one, but still a bug) go to production the day before a code freeze, and there it stayed , just to avoid having to justify an "emergency deployment" to managers and directors.

But hey, to each their own. I’m not the one paying the bills, and if the ones paying the bills are happy with this, all I can do is try to change their minds.