During peak traffic season, the topic of code freezes often comes up as a way to deal with the influx of exceptionally high traffic during that time.<\/p>\n\n\n\n
Code freezes may seem like an outdated concept nowadays, a leftover from the days when rigid Waterfall methodologies offered the only option for product development and release.<\/p>\n\n\n\n
The whole concept of stopping production and delaying release\u2014just to test for bugs and other functional issues\u2014has no place in Agile and DevOps<\/a> practices where code is tested and verified at each stage of the development process. <\/p>\n\n\n\n At least that seems to be the general consensus for many tech teams.<\/p>\n\n\n\n But does it hold up? Once you scratch the surface of the most common arguments against incorporating code freezes into Agile product management, will they still seem archaic?<\/p>\n\n\n\n In this article, we\u2019ll explore the three main arguments against incorporating code freezes into your Agile product management, and we\u2019ll break down where those arguments fall apart, all to help you make a better decision about whether or not you should incorporate code freezes into your organization’s workflows.<\/p>\n\n\n\n We will first start with what a code freeze actually is to understand whether it still has a place in modern software development.<\/p>\n\n\n\n A code freeze is a traditional practice among developers to stop making changes or pushing new code to ensure site or app stability during a certain period of time<\/strong>. A code freeze is usually implemented during periods when higher traffic than normal is expected, particularly for e-commerce websites during the holiday season. <\/p>\n\n\n\n What does this mean? During busy periods in the e-commerce industry, you are temporarily refraining from making any changes to the website. Any changes to impact the user experience during peak traffic time can ultimately result in a loss of conversions and profit.<\/p>\n\n\n\n In other words, a code freeze is done as a way to safeguard against any potential mishaps because of the extra load on a website<\/strong>. <\/p>\n\n\n\n Let\u2019s look at a practical example: developers decide to introduce a new code change during Black Friday when there is a high volume of traffic with shoppers looking to get the best deals. However, it turns out that there\u2019s a bug they hadn\u2019t anticipated. With the website facing downtime as developers quickly attempt to fix the issue, this may result in loss of potential revenue as customers are unable to complete their purchases.<\/p>\n\n\n\n To avoid this worst case scenario, developers instead impose a code freeze time, a time where no more code changes are made. This is done to ensure a website is up and running without any issues until this high traffic period ends.<\/strong><\/p>\n\n\n\n We will discuss the idea behind the Agile concept<\/a> to better determine whether it aligns with code freezes before we explore the most common arguments against them.<\/p>\n\n\n\n The Agile methodology seeks to break up projects into regularly iterated cycles known as sprints and is largely driven by consumer feedback. This helps teams deliver more value to consumers quickly.<\/p>\n\n\n\n In other words, this methodology encourages continuous iteration and improvement of products and testing<\/a> throughout the software development life cycle<\/a>.<\/p>\n\n\n\n By breaking down development into sprints, cycle time is reduced, increasing speed-to-market and allowing teams to respond to market demands faster.<\/p>\n\n\n\n With this in mind, a code freeze may potentially reduce the ability for teams to quickly deliver value as they impose a freeze period.<\/p>\n\n\n\n Next, we\u2019ll look at some of the common arguments against code freezes in the context of an Agile methodology.<\/p>\n\n\n\n This argument is pretty simple and concrete\u2014 modern Agile methodologies and tools have eliminated the need for a dedicated QA and testing window.<\/p>\n\n\n\n Agile methodologies such as peer code reviews, pair programming, and the constant monitoring of system health give you much greater visibility into an application or feature\u2019s performance while it\u2019s being developed. Bugs and issues are easier, and more likely, to be caught during development itself, and resolved prior to any dedicated testing and QA activities.<\/p>\n\n\n\n The more refined your approach to Agile, the more you will try to shrink this window of time. The most refined current approaches to Agile are Continuous Integration and Continuous Deployment (CI\/CD)<\/a>,<\/p>\n\n\n\n These processes aim to break development into small, incremental changes in order to \u201crelease\u201d changes to the code as quickly as possible. In the purest application of CI\/CD, development and release barely exist as distinct phases\u2014 new code is integrated into the application almost as soon as it\u2019s completed.<\/p>\n\n\n\n New tools have also automated many tests. They constantly evaluate code to make sure it\u2019s clean and ready for production at all times. Issues are identified in real-time, and alerts are immediately sent out to resolve them, reducing the volume of manual tests that need to be performed.<\/p>\n\n\n\n The result of these new Agile methodologies and tools is easy to see. Most of the core testing and QA activities performed during a code freeze are either being performed during development, or performed by software.<\/p>\n\n\n\n In Agile, software and features now exit development at a much higher level of confidence than they used to, making a dedicated code freeze harder and harder to justify.<\/p>\n\n\n\n This second argument is a little higher-level. Basically, it argues that code freezes don\u2019t have a home in Agile methodology because they break one of this methodology\u2019s core principles\u2014 reducing the time between development and release.<\/p>\n\n\n\n By contrast, you need to maintain distinct development and release phases if you\u2019re going to deploy code freezes. After all, that\u2019s where the code freeze lives\u2014 in between those two distinct phases.<\/p>\n\n\n\n Instead of trying to minimize or eliminate that window of time between development and release like most of Agile methodology, code freezes force you to formalize this window to the point that you need to build your development and release schedules around it.<\/p>\n\n\n\n If code freezes don\u2019t align with core Agile principles, then it\u2019s hard to make the case that they still belong in the methodology.<\/p>\n\n\n\n This final argument is a big one, and it includes a few different angles.<\/p>\n\n\n\n Firstly, it argues that code freezes add a lot of complexity and additional moving parts to your roadmap, and naturally increase the chances that something will go wrong and throw off your timeline.<\/p>\n\n\n\n Even if nothing goes wrong, the work involved in code freezes is time-consuming and unpredictable (as you don\u2019t know what bugs you will find or how long it will take to fix them), that by simply adding code freezes to your roadmap you will create slower development and release cycles.<\/p>\n\n\n\n It\u2019s worth pointing out that, on the one hand, when you\u2019re in a code freeze, developers will continue to develop code but without integrating or testing it while they wait for the freeze to be over. This will result in a build-up of code leading to greater risks and instabilities which could significantly slow down the momentum of your CI\/CD processes. <\/p>\n\n\n\n On the other hand, developers may want to get new code changes out before the code freeze period begins. This could lead to incomplete or poorly written code which may not undergo the usual thorough testing for the sake of saving time as they rush to get projects done before the code freeze. The end-result is lower-quality, less comprehensive software and applications.<\/p>\n\n\n\n Furthermore, code freezes may reduce your development team\u2019s productivity. While Agile in general, and CI\/CD specifically, keep your developers constantly working in an unbroken chain of productivity, code freezes force your developers to stop work at pre-defined intervals.<\/p>\n\n\n\n In other words, they could break your CI\/CD pipeline.<\/strong><\/p>\n\n\n\n By doing this, you will break your team\u2019s rhythm and force them to try to work around your code freeze policies, instead of finding and maintaining whatever flow makes them most productive.<\/p>\n\n\n\n At this point, it\u2019s looking pretty bleak for anyone who still wants to include code freezes in Agile methodology. There are some very compelling arguments and an overall solid case that, since the development of modern Agile methodology, code freezes have become:<\/p>\n\n\n\n But while these arguments are compelling, and contain a lot of accurate information, they are not bulletproof. And there are fundamental flaws within each that need to be discussed before closing the book on code freezes as a useful element of Agile product management.<\/p>\n\n\n\n Automated QA and Agile development practices have increased the quality of code as it\u2019s produced, that\u2019s a fact. However, just because a piece of code has passed unit testing, that doesn\u2019t mean it\u2019s actually production-read<\/a>y.<\/p>\n\n\n\n Even the most refined CI\/CD approaches don\u2019t always include critical steps\u2014like regression testing\u2014that ensure a piece of code is defect-free. When it comes down to it there are just some things you can\u2019t test and resolve while a piece of code is in production.<\/a><\/p>\n\n\n\n If you choose to utilize code freezes, you aren\u2019t going to give up the benefits of automated QA and Agile best practices.<\/p>\n\n\n\n You and your team will simply catch your code\u2019s smaller, more trivial problems during production, clearing the decks to focus on catching larger, higher-impact issues during your freeze, such as the overall stability and reliability of your new software or feature.<\/p>\n\n\n\n While Agile is designed to reduce the time between development and release, there\u2019s a big difference between trying to reduce this window, and trying to completely eliminate it. Doing so would be next-to-impossible, especially for larger projects.<\/p>\n\n\n\n The code freeze may be very short in CI\/CD\u2014 or may only apply to a specific branch while development continues on other branches<\/a>\u2014but it still exists.<\/p>\n\n\n\n No matter how refined Agile became, there is almost always going to be a point in all development and release roadmaps where a new piece of software or feature will be evaluated in a fixed state before it goes out to real-world users.<\/p>\n\n\n\n If you utilize code freezes, you will add a new step to your development and release cycle and any time you add a new step to any process, you slow down that process and you create a new potential failure point. Code freezes are no exception.<\/p>\n\n\n\n But it\u2019s important to take a step back, and to take a broader view of this slowdown and lost productivity.<\/p>\n\n\n\n If your feature has bugs, you will need to fix them, regardless of whether you caught those bugs during a code freeze, or whether they made themselves known after release. From a pure development perspective, the amount of time needed to fix them will be about the same in both scenarios.<\/p>\n\n\n\n But if you\u2019re dealing with bugs in a live environment, you have a host of other issues you need to take the time to deal with, including:<\/p>\n\n\n\n The list goes on. There\u2019s nothing more complicated, time-consuming, and destructive to productivity\u2014for you and your team\u2014than releasing a broken feature or product. Code freezes minimize the chances of this happening.<\/p>\n\n\n\n And as to the argument that code freezes lead to lower quality features and products because they reduce the amount of business requirements you can collect?<\/p>\n\n\n\n Your business requirements will always be little more than a \u201cbest guess\u201d as to what your product or feature should function like. The most valuable requirements will always come from real-world users when deploying your product or feature in real-world scenarios.<\/p>\n\n\n\n As we\u2019ve already mentioned, a code freeze is done as a preventative measure against risky and\/or faulty new code changes during sensitive periods. <\/p>\n\n\n\n However, a code freeze could actually increase risk. As developers continue to work on new changes that don\u2019t get released during the freeze period, this means that the next release will have a pile up of commits making this release incredibly risky. <\/p>\n\n\n\n If any issues come up, it will be that much harder to pinpoint the source of the problem which means more time is wasted trying to locate and fix it.<\/p>\n\n\n\n This is where feature flags<\/a> come in. Using feature flags means that developers no longer need to depend on code freezes during high traffic times to reduce the risk of code changes. <\/p>\n\n\n\n By decoupling deployment from release, feature flags allow developers to deploy a new feature or code change into production and toggle it off so it\u2019s not visible to users and then gradually release it to specific user sets<\/strong>\u2014for example, internally within your organization.<\/p>\n\n\n\n As a result, teams can continuously ship new code and work on new features with customers none the wiser as they will be hidden behind these flags and can be toggled on or off at any time. Teams can also turn off\u2014 or roll back\u2014 a buggy change at any time with a kill switch<\/a> so users no longer have access to it while it\u2019s being fixed.<\/p>\n\n\n\n In summary, feature flags give teams more control over the release process and help reduce the risk of deploying into production, especially during particularly sensitive, high traffic periods without negatively impacting the user experience. <\/p>\n\n\n\n Ultimately, code freezes still play an important role to avoid downtime or unexpected bugs during exceptionally busy times in the year.<\/p>\n\n\n\n Every e-commerce website is different so you will need to decide if a code freeze is the right choice for your website. If you do decide to implement a code freeze, draw up a carefully detailed plan in advance with your development team. <\/p>\n\n\n\nWhat\u2019s a code freeze?<\/strong><\/h2>\n\n\n\n
What does an Agile methodology entail?<\/strong><\/h2>\n\n\n\n
Argument 1: Code Freezes are Irrelevant and Unnecessary<\/h3>\n\n\n\n
Argument 2: Code Freezes Break a Core Agile Principle<\/h3>\n\n\n\n
Argument 3: Code Freezes Lead to Slower, Lower-Quality Releases<\/h3>\n\n\n\n
Making the Case for Code Freezes: A Losing Battle?<\/h2>\n\n\n\n
\n
The Problem With Argument 1: Automated Testing Is Not Comprehensive<\/h3>\n\n\n\n
The Problem With Argument 2: \u201cReduce\u201d, Not \u201cEliminate\u201d<\/h3>\n\n\n\n
The Problem With Argument 3: Rethinking Speed and Quality<\/h3>\n\n\n\n
\n
How feature flags can replace code freezes<\/strong><\/h2>\n\n\n\n
Is it time to kill the code freeze?<\/strong><\/h2>\n\n\n\n