We see it in the government every day. A bill is placed in hopes of being advanced, but there are a bunch of "riders" attached which means that saying yes to the main features of the bill also means pulling through these additional riders which may be unrelated, but may also have a great and real impact. The same holds true for software. You get the okay to make a change to a system somewhere, but you figure "hey, since I have the code open for updates, let's do a few more things". And so begins the issue of larger releases.
Do Less, More Often
The concept of rapid releases has become popular with good reason. CI/CD (Continuous Integration/Continuous Deployment) allows us to move from big releases to more iterative, rapid releases. The goal is to reduce the risk with each subsequent release as the level of change is minimized at each release. This is true even though it happens more often.
Think of what it is like to roll a snowball. It may seem like you are moving more snow by making the snowball larger. Guess what happens when it becomes large? It is heavy and not easy to adjust or steer. Same thing goes for software. It's better to have 20 snowballs 3 inches in diameter than it is to have one giant snowball that quickly becomes unruly to move around.
Regularity Lowers Risk
It may seem counterintuitive to say that putting out twenty releases a month is less risky than putting out one per month. The rationale of rapid releases becomes obvious when you look at the rest of the methodologies we embrace to do this rapid style of delivery. Typical processes will include unit test, integrated functional tests, and a practice which becomes popular as well is the modularizing of the application. Hmmmmm....sounds like a thing we could call micro-services, but that's a different blog all unto itself.
In order to enable the practice of regular releases, the development patterns always seem to align to better practices. If you have to release once every three months, you are less likely to have unit test throughout your development because you have much more time to "work out the bugs" with the long release cycle. It's a self-fulfilling prophecy by creating more opportunity for terrible practices and bad development patterns.
If you only suffer once every three months then you are likely to just take a chance at it. If you have to be sure of the strength of your code and infrastructure every couple of days then I doubt you're willing to take on the paging duty for those releases. This is the SRE (Site Reliability Engineering) approach to things. Owning the process more and having SRE thinking means that we will end up with less large-scale errors. Nothing is error-free, but it will be lower risk.
Change Freezes = Risky Ventures
My history in the industry crosses many different companies. Many of which observed stringent change freezes during critical holiday periods or processing periods like tax time and fiscal year end. The result of having these sometimes multi-week lockdowns for moving applications and changes to production is that we ended up bundling lots of changes all at once on the first release day after the change freeze.
The resulting release weekend would trigger incredible amounts of risk and usually a high number of errors across many systems because of all of the moving parts involved. This was a proving ground for the value of rapid and regular releases. What is worse is that the reaction to bad changes is often more freezing of changes. The result of that is more bundling of changes, thus increasing the risk again and again.
More Releases = More Goodness
Whether better development and operational practices creates the ability for rapid releases, or rapid releases creates better development and operational practices is neither here nor there. That's the chicken egg discussion. What we get in the end, either way, is better IT. That's a goal which is worth shooting for.