There is something to be said for the official start of the holiday season: the feasts, the family and friends, and gifts. Especially in the IT space, there may appear to be a lull, especially if your organization has code freezes in place. For anyone in the IT or engineering part of the org chart, it is anything but quiet.
The idea behind the change freeze, or quiet period, is to ensure critical functionality continues uninterrupted. From a product engineering perspective, this is intended to stabilize the product before shipping, and has always been treated as a misnomer. New functionality would be frozen out, but changes would continue to be allowed if they were considered bug fixes. What this would mean is that a flurry of changes would be made before the freeze goes into effect, ensuring the resulting system is less stable and requiring more effort to fix the resulting conflicts. Additionally, if the feature is considered critical, then the “new” functionality would be re-framed as a fix to bypass the process.
In the enterprise, the change freeze usually coincides with the end of year accounting period in many cases, or the holiday shopping season for retail and travel. There are some who would suggest that inaction could result in worse issues citing the case of services that are normally restarted during a normal update cycle, and without the scheduled updates, they turn into ticking time bombs that can cost tens of millions of dollars in lost revenue and productivity due to your team debugging and resolving these corner cases. Granted this argument doesn’t take into account the emergency changes that go in to both troubleshoot and resolve the failing system. Changes that have far less testing and oversight because, as we all know, changes made under duress are not tested.
If you talk to anyone from Silicon Valley, they would say this is why they constantly push out code changes, and where the agile methodologies come into play: continuous incremental changes at all times where the latest bits are always running. The idea being if your business operates this way 11 out of 12 months of the year, then why the last month be any different? While it may work for those with the motto of moving fast and break things, a majority of enterprises are more conservative with their changes and their testing/verification process because more than the user experience is at stake.
At the end of the day, it boils down to risk tolerance. With legacy systems, they fall into two camps: either rock solid to the point where nobody knows they exist because they work that well, or they are so unstable that everyone knows they exist and wish they can replace it. The hope and expectation is that your environment is like the former, but more than likely it will be the latter. Regardless of whether there is a quiet period. The risk can be minimized by turning it into a quiet period instead of a full on freeze. Low or non-impactful changes make decent candidates while replacing your database may not.
What does your end of year period look like? Do you have a quiet period where no changes are allowed whatsoever? Do you allow nominal changes and updates, but disallow major changes? Or do you operate as if there was no quiet period?