That's not the mindset of enterprise IT though. The mindset of enterprise IT is "if it works, don't touch it." This mindset developed because of decades of dealing with arcane, complicated software that was at the same time critical to business operations. I'm aware of a major university that still has a three-week "change freeze" at the start of every semester because of this attiude and I'm sure they are not the only one.

Three weeks freeze twice a year during the most critical time does not sound that horrible to me.

Software developers tend to break system with changes. That is not some kind of mythical rare issue - that happens often (with some vendors very often).

Agreed. A company that doesn't have change freezes at the most critical times has very poor practices.

I've worked in enterprise security teams for the last decade. This is spot on. It's retarded and will never change because there is no accountability. Corporate IT don't give no fucks.

Corporate IT is doing what software developers have taught them through experience and pavlovian condition:

Don't touch anything, because it will break if you touch it.

IFF people who release software learn how to release security patches and bugfixes that don't include new features or break existing parts (except when breaking changes are actually needed), then, after several years of good results from pushing changes, Corporate IT will be conditioned to just push security fixes, it's not a big deal, plus it's important.

Then let's hope Equifax shakes the foundation of their egos and they start to give fucks about this sort of thing.

Right. Which is why ci/cd and devops, etc were invented. If you're not patching and updating frequently, you're committing business malpractice.

The "change takes time" issue does not happen because of technical problems. It happens because of organizational problems. Technical problems with patching are easiest to solve.

Side note: fully tested within hours assumes small stable software. Large software with frequent changes into it needs to be manually tested. If you have microservices, you still have to test whether something important did not broke.