Our code froze! A lot of companies include some sort of code freeze process in their development process, but few truly honor the meaning, and instead simply use it as just another artificial milestone that they can celebrate. But what exactly is Code Freeze, and why is it useful? At a very basic level, code freeze simply means that no more changes are allowed to be introduced into source control. Generally this also means that all defects have either been fixed, or they have been reviewed and its been decided to either not fix them, or delay fixing until another release. Usually the first build after code freeze is declared a Release Candidate.
The one important part of the code freeze process, which many companies fail to implement is the shelf period. If you freeze code, and then immediately release your software the next day, then code freeze is pretty meaningless. I personally recommend at least a one week shelf period after a release candidate (depending on the size and complexity of the application). During this period of time, your developers and testers should continue testing and using the application. Because nothing new is introduced into the code, this provides a period where everyone can feel confident that things are going well, and extra regression testing and user acceptance testing is performed.
Code freeze also signals an important change in the development process. Before code freeze, defects are fixed at will by people, and changes can be introduced rapidly. During code freeze, extra scrutiny is placed on any defects that are submitted, and generally only high priority defects are considered for fixing after a review process which includes the development lead, test lead, and project managers. Defects that include changes to functionality should be flat out rejected, and only defects to already included functionality should be considered. Also, any code changes that are made during the freeze must be associated with one of these defects, and must be reviewed by another developer on the team before it is to be included in another release candidate build. Any changes made to the code that aren't related to the defect should be rejected by the reviewer. I don't know how many times I've seen people try to sneak in changes during code freeze, just because they wanted to "clean up the code". Now is not the time for those types of changes. The reviewer should also verify that the change is safe, and that it actually fixes the defect. The idea is not to introduce a new bug when trying to fix this one.
If multiple release candidates are created, it is up to project management whether the code freeze time will be extended. This is generally done after examining the nature of the defect, and the also the size of the change, and how much code was effected. If something as small as a spelling mistake is found, then code freeze would not be impacted. However, if a generic library method is changed that is used by various parts of the application, then you'd want to extend the freeze to regression test the affected areas.
Remember, code freeze isn't just another meaningless milestone. It should include process change, and should help to introduce confidence and stability to the software development process just prior to deployment.