The author seems to be mixing his messages. His second sentence ("What really happens, of course, is that the system in question becomes booby-trapped with ext

The author seems to be mixing his messages. His second sentence ("What really happens, of course, is that the system in question becomes booby-trapped with extra risk. As a result, problems are more likely, and when there there is even a slight issue, it has the potential to escalate into a major crisis.") I -completely- disagree with, as phrased/contextualized, both from a theoretical and an experienced perspective (week long change freezes prior to important events have led to fairly straightforward operation cycles, whereas deployments lead sometimes to unexpected new features, new UI elements, new bugs, etc, which people on a trade show floor probably don't want to have to deal with when demoing). However, his conclusion (the big long paragraph at the end that I won't bother quote) is suitably vague and abstract and filled with good advice (while ignoring subtleties and specifics, such as when he admits 'Frozen systems can run as-is briefly', but then immediately goes on to describe the issues with leaving them running as is for long periods) that I can't directly disagree with it. In short, I'm not really sure what to do with this. "Improve your deployment processes!" Well, sure, that's always a good thing. But that's mostly orthogonal to whether we have change/deployment freezes (they don't happen because of fear of the deployment process, but because of fear of the new code and the changes it brings). And the entire argument seems to posit that all change freezes are bad, yet he both throws a bone that they at least are tenable for brief periods in his conclusion, -and- ignores the body of evidence pretty much everyone has that short change freezes -do- grant comparative stability, which may make for sound business decisions (I personally have sat in a demo where key functionality was broken because of a last minute check-in of some library code from someone on another team that they had not properly tested. That stuff -happens-). Were the tone changed to, sure, include all the risks inherent in a change freeze, but to rephrase the arguments to show that as time goes on an inflection point is reached such that the cons outweigh the benefits, and posit that that point is reached much faster than you might think, I'd be completely on board. As it is...meh. EDIT: Maybe the author is specifically targeting web applications with frequent pushes to prod, i.e., the code you're freezing hasn't had time to shake out any of its issues, as compared to a versioned release that has been in production, and patched as necessary, for a week or two prior to the freeze, and the code freeze is just applicable to new versions, not patches considered critical.