Understanding the Purpose of a Code Freeze

A code freeze is a period of time when no new code can be added to the codebase or released to customers. This practice is commonly implemented around the holidays to allow the development team to take a break without worrying about changes to the codebase, and to prevent any issues that may arise from new code being added while the team is not available to address them. Code freeze can also be used to ensure the codebase is stable before the start of a new year or quarter.

It helps to ensure the codebase remains stable and free of bugs during holidays, and can be particularly useful if the bank is planning to launch a new product or feature during this time. A code freeze can also reduce workload for employees who are in the office and prevent last-minute changes from causing issues for users. It can also allow the bank to focus on other tasks that may be necessary before the end of the year, such as preparing year-end reports or planning for the next year.

Drawbacks

There are a few potential drawbacks to instituting a code freeze:

Reduced flexibility: Code freeze can reduce the flexibility of the development team, as they are unable to make changes to the codebase during this period. This can be especially problematic if there are urgent issues that need to be addressed.

Delayed progress: Code freeze can also delay progress on new features or other work that is in progress. This can be frustrating for the development team and can impact the overall schedule for a project.

Miscommunication or misunderstandings: Code freeze can also lead to miscommunication or misunderstandings, especially if not all team members are aware of the code freeze or if there is a lack of clear communication about the process.

Increased pressure on the development team: Finally, code freeze can increase the pressure on the development team, as they may feel the need to complete as much work as possible before the code freeze period begins. This can lead to burnout and decreased morale.

Packed releases: After the freeze, teams might have accumulated code that hasn’t been released, making the first release after the freeze a risky one.

Then why companies do it?

It can be frustrating if your team is unable to release code, especially if you have a stable team with automated tests and monitors in place. However, it’s important to remember that no team operates in isolation. For example, changes to a database may require assistance from the DBA team, who may be operating at a reduced capacity due to holiday vacations. If other teams also need their help during this time, the DBA team’s service level will be further reduced.

Ultimately, it’s a risk-based decision. We must consider two main risks: the risk of disrupting something during the holidays, versus the risk of disrupting it after the holidays when we have accumulated more features. In the banking industry, it is rarely worth taking the first risk for the sake of delivering a feature during the holiday season. Therefore, we typically choose to take the second risk, knowing that the majority of the workforce will be back and available to support any incident or disruption.