> As a company, it's great to have a process for incremental changes, but you also need to have a process for critical hot-fixes.
And as soon as you do, everyone thinks that their problem is a good candidate for the critical hot-fix path. At the very least, you now have to sink minutes per day into arguing them down from using it. Worth it? Possibly. But not always.
If you have a single (actually) business critical incident that cannot be resolved, the company will fail. It's called risk management. You spend minutes per day arguing with idiots to not have the company fail in an emergency.
You need a good operations team with the authority and willingness to say "no" with overrides coming only from senior management, the authority to say "yes" for the obvious stuff, and a direct line to senior management for grey areas they're not comfortable making a call on by themselves.
The operations team will spend a few months saying "no" a lot and justifying their decisions to management. Eventually it will slow to a trickle except for a few really stupid people who lack reading comprehension and any sense of pattern detection. Management will eventually get tired of it and forbid the stupid ones from making hot-fix requests.
The code behaves differently after some event happens.
Midnight. Y2K. Daylight Savings Time change. Leap Day. Congress changes when Daylight Savings Time happens and one component in the system didn't know about it. Year 2038 problem.
> It [sic] we don't do this right away, we'll have to have a layoff.
As a company, it's great to have a process for incremental changes, but you also need to have a process for critical hot-fixes.
You're a phone company, and adding a new feature should take months. I get that.
You're a phone company, and because of an unforeseen Cinderella problem, 10% of your customers can't make phone calls. At all.
It is unacceptable to have a one-size-fits-all process, no matter what your business is.