The “Code freeze” phase, right before going live.
- Sep 22, 2009
I guess that multipe teams have the “code freeze” phase, which simply means to get the software stable right before going live several days later.
But what does a “code freeze” really mean? Is the code really ‘frozen’ or are you allowed to fix bugs that come out of the tests in the last remaining days before the release?
In our team, a code freeze is not a real code freeze. Because if that were the case that would mean we would be afraid to fix bugs. And fear is not a good sign for having a code-freeze.
Quoted from Curtis R Cooley, Approaching code freeze and.. The big milestones were: Feature Freeze, Code Frost, and Code Freeze. These were intended to reduce risk in a non-agile development methodology, but they were all completely driven by fear [..]
During Code Frost, only severe and critical bugs can be fixed, since any change to the system could introduce more bugs. This is basically a risk and fear based paradigm. Code Freeze means there are no critical bugs and the ratio of severe bugs to the rest is below some number. After Code Freeze no code
is written unless QA finds either a critical bug or enough severe bugs to cause the ratio to rise above the acceptable threshold. The project manager was not amused when I pointed out that you can get the ratio below the threshold by introducing more low level bugs.
On one hand it’s nice to have a code freeze period, but on the other, it’s in nobody’s interest for you to ship a product with critical issues large enough to make your customers walk away.
If the issues are serious enough, no code freeze would stop me fixing them if it were my product. And as a matter of fact, fixing bugs during the code-freeze period is exactly what we do in our team. We actually use the term ‘code freeze’ as ‘feature freeze’, according to wikipedia anyway. No new features and enhancements are allowed during the code freeze phase: those have to wait till the next iteration. It might be tempting to fall for the bargaining game of our clients, but if enhancements came too late on the wish-list they are well… simply ‘too late’. Bad luck, that feature will be in the next release for sure! On the other hand, bugs? Sure we can fix them! We have our unit-tests in place, so there’s no reason to fear fixing. Let’s move on to another stable release!