The cost of a code freeze
So you’re thinking about doing a code freeze in your company, or maybe you already are. This article discusses the pros and cons and potential solutions to the common pitfalls.
A “code freeze” is general the period of time in which developers of a team based software development project are barred from the check-in of code into the source code control repository. Code freezes are used as a way of obtaining a clean version of code for preparation of a release. A lot of companies use these for internal build releases as well that are generally provided for the Quality Assurance department.
Is a code freeze a good thing? Well, maybe. Conceptually it sounds like a great idea; tell all developers to hold off on the check-in of code for a set period of time while a build is prepared off of the active development branch of the source control system. Proponents of the standard code freeze argue that the lock down period of time is necessary in order to properly create a build that is functional. The issue that arises is really around the length of time the code freeze is truly in effect. If the standard build and assurance process lasts a few hours, the impact is relatively negligible. If in turn the process takes a day or longer, then the impact to the development cycle is truly felt.
The impact of the denial of code checkins on an active project is dependent on a number of factors; the size of the team, the lack of source code isolation of the distributed tasks, and the velocity of the tasks. These variables interact in a non-definitive but potentially exponential way. The higher any of the values are, the more the value of the other variables affects the cost. For example, the more developers there are on a project the greater the impact of higher velocity and lack of source code isolation on the tasks.
Say you have X developers, they work on code with an isolation level that has a probability of interaction of Y (likelihood a developer is working on a section of code another developer is also working on), and they are working on tasks at a velocity of Z. Let us also assume the code freeze occurs for H hours. The variable interaction would be similar to H * ((X2 * Z) * Y. While the math on this particular equation is very loose and up for debate, the potential impact is obvious. We can determine the true impact if we were to take on an actual experimental situation (or really put a lot more thought to it than I did) to find the actual impact.
What the above is basically showing is that the cost of the code freeze increases the longer it lasts and is dramatically more when a larger number of potential interactions (developer activities) are introduced.
What can be done about this?
The code freeze employed by some companies is the hold all code and wait until a valid build is created from the development/active branch of the source control system. The implied benefit is that developers can check in code ONLY to fix the actual build process and get the initial assurance verification tests to complete successfully. The cost of this particular method is generally not worth its benefit.
An alternative to this particular cycle is to use a form of the Branch by Purpose pattern (“The Importance of Branching Models in SCM.” IEEE Computing Practices. 0018-9162/02.) recommended by Walrad and Strom which dictates that you create source branches when the code in the branch will be used for a particular purpose; a bit self explanatory in nature. This method allows you to have a code freeze for only the period of time it takes to snapshot the branch. You can then build your releases of the branch. The developers will encounter minimal impact due to the brevity of the code freeze and defects can easily be fixed in the secondary branch and merged back into the main branch if necessary.
The utilization of my interpretation of this pattern is quite simple. The source control is created with a main/active development folder to house the current iteration of source code. You then create a quality assurance branch which you use to send copies of the main/active branch when you need to create builds to send off to the quality assurance team. This format allows the development team to continue on with work while the build team uses the QA branch to produce the QA builds. Any code changes to fix the process would be made in this branch and merged back to the main branch.