Welcome, everyone, to the ThoughtWorks Technology Podcast.

I'm one of your regular host, Neil Ford, and I'm joined today by another of our regular

hosts.

Yep, this is Mike Mason, and this is very exciting because we're actually in-person in our

New York office, one of the first in person's in person meetings

that we're doing this year where we put together the radar. And as part of the ThoughtWorks

Technology radar discussions, we we often have some pretty interesting things to talk about

that sometimes make it into podcasts. So that's what we're going to be doing today.

So Neil and I are joined by Cassie Schum. Hi, Cassie. Hello. And we're also joined by Ian Cartwright

all the way from Hamburg. Hi, Ian. How you doing? Hi, dear. And one of the things you may have

heard us talk about before in these podcasts is the category of things that were too complex to blip on our radar.

And we're here putting together our radar and a topic that arose a lot of passion that ultimately, alas, fell to the too complex to blip category, is the topic of code freezes considered harmful.

And that's what Ian and Cassie are here to talk about.

So let's start by describing what the bad thing is.

So what is a code freeze?

So a code freeze is essentially either a team or organization mandated freeze on all commits from developers

and engineers to the code base. And this usually, as I've seen, it lasts for potentially many

weeks up to even up to a month or two. And so this is usually done because there is fear that any code that goes into the code base

at this time would actually break something major in production.

And this is normally done before a big event like a Black Friday for the e-commerce or a big banking transaction

day where it would be very detrimental to the organization if anything bad happened in production

on those certain days.

...