Uncharted Waters

Apr 19 2017   5:49PM GMT

The Code Freeze Myth

Justin Rohrman Justin Rohrman Profile: Justin Rohrman


A few years ago I was working with a development team at the end of a very long release cycle. About 15 of us were gathered in a meeting room giving our status update. Most of the developers said they were done with implementation and were either waiting for feedback from testers, or were going to start looking at the next sprint. The rest of the developers were still working on building features for this release.

After everyone gave their updates, the manager said we were about to have a code freeze. No more checking in code.

Developers were still implementing features, testers were still finding bugs that would probably need to be fixed, and we had not produced a candidate build yet. But, out manager said we were going to have a code freeze.

Code is never frozen until the product is shipped. And, for companies using continuous delivery that might only be for minutes or seconds at a time. Most of my experiences in agile have looked like this. Developers write code for seven days of a two week sprint. At this point, a manager might say they are in code freeze. No more development is happening. But then the testers jump in. On Wednesday of week two, the test teamstarts investigating the new code changes. They find and report some bugs. Some are obviously problems and get fixed with no outside discussion. Some are questionable and go through a group discussion to see if they really need to be fixed. Other don’t get fixed at all and linger in the bug tracking system until someone deletes it months down the road. I don’t think that is idea, but that was my experience.

I think the term Freeze misleads people outside of the technical group and deludes people inside of it, so I like to use other terms like ‘hardening’ or actual sentences to describe what is happening instead of single words or technical catch phrases.


Code freeze is a short hand way of talking about adding control structures to making code changes. The sprint is a near free-for-all. Developers are constantly writing and checking in new code. Each check in introduces a little bit of risk to the release. After implementation is done, the only new changes are bug fixes. Unless a product manager comes by wanting a last minute feature, or a forgotten promised feature appears in the backlog. After the initial fixes for bugs that are obvious problems, the funnel gets tighter. At this point, a triage team might meet to talk about any potential code changes. At smaller companies is just a couple of people deciding if the bug really needs to be fixed right now. At larger companies, this is probably an official committee.

Fewer and smaller code changes are allowed into the build the closer a team gets to a release. The software train is always moving forward. Up until the very moment a product is shipped, there is always some chance a code change could be made. After the product is shipped there is the possibility of bug fixes.

Managers like to use phrases like this to mark milestones. Code freeze is easy to say, it has a nice ring to it. It is also a complete myth. I like to use hardening instead because it doesn’t allude to code not changing anymore. The code never freezes.

3  Comments on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • shimonb
    Very interesting article, and I find it very easy to relate to the description of the "Code Freeze" evolution.
    10 pointsBadges:
  • shelldozer
    Hugely agree! Some organisations wisely use a checkpoint named "only fixes for overt defects", and the use of the word "defect" instead of "bug" is quite clever - it causes people to consider how they can justify their pet last-minute-code-change, rather than just bunging it in and the heck with it.
    40 pointsBadges:
  • Justin Rohrman

    Thanks! I'm glad you enjoyed the piece. The language around bugs and defects is really interesting to me. It is easy to re-categorize something originally documented as a bug as a a feature or as out of scope. This makes milestones seem like clear cut, obvious points in a release cycle rather than the squishy rules of thumb that they are. 
    2,130 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: