You’re right, I overstated my case and I understated the language that many people use. Therefore I apologize, allow me to take a step back try again.
So… on the day an update is rolled out, yes it is absolutely possible to simply roll it back. This is a basic, standard feature of modern software development.
Mind you, it’s not as simple as clicking one button, but it is standard functionality for software roll outs. It also becomes increasingly difficult as time progresses, it takes a more work to roll back a deployment after 24 hours, 2 days, 5 days, etc. because so much of the data that the application manages has changed. But even then it’s not impossible, and depending on the specific software in question it may or may not even be particularly difficult.
The problem in these discussions is that you continually talk as though it’s not possible, or it’s mind-bendingly difficult. To put it simply, you’re wrong. I don’t know where you’ve gotten this idea from but it’s factually incorrect.
I’ve done dozens and dozens of software deployments in my career (almost enough to say, “hundreds”, but not quite). I’ve done deployments that took 5 minutes all the way up to a 24 hour maintenance window, depending on the size and complexity of my application. But in every deployment no matter how large or how small, in addition to practicing the deployment in a test environment we also test doing a rollback in that same environment. If we can’t get it right the first time, we reset the test environment and deploy/rollback again, until we get it right so that we know in advance it can be done in production before the production system is ever touched.
This is how professionals deploy software.
Building a rollback plan is a basic, standard element of any software deployments in a professional environment. This is not something people learn about in school, it’s not part of taking any computer science curriculum or programming class and there are no classes in “how to do rollbacks”, but it happens in every software company that is run by professionals.
And, more importantly, once you learn how to do it, it’s just not that hard. If a deployment team knows how to do their job, doing a rollback takes only slightly more time than the original deployment did (about 10% more time on average). It does not require and extended outage nor does it require the entire company to go into emergency mode.
Anyone who argues that they’re excessively difficult, or even worse “not possible”, does not know what they’re talking about. I don’t mean this as an insult, but that includes you, you simply don’t understand how software deployment works. For the record, I’m not suggesting you don’t understand development, that’s a different skill, what I’m saying is specific, you don’t understand deployment in a professional environment.
That’s the end of point #1: Rollbacks are a basic, standard feature of modern software development, they’re not as hard as you think they are.
Now on to point #2…
In that case you need to improve your messaging to people. What you could be doing is saying, “They’re not going to roll it back, but if we lobby them hard enough they might restore it in the future.” But instead what you say is, “It can’t be done, everything can only move forward.” It shouldn’t be hard to see what is different about those two messages. Whether you realize it or not, the message that you repeatedly send is, “It can’t be done, shut up.” I’m guessing that’s not your intent, so maybe spend some time thinking about how you present your responses.