The opposite problem is much more common and shouldn't be downplayed: A developer or designer using the "every change breaks someone's workflow" exaggeration as an excuse to break a workflow.
The fact that any change to software people are used to using will bring pain to the users shouldn't mean that devs automatically prefer or avoid breaking workflows. What it should do is encourage actually thinking about the cost/benefit (to the user) of the change.
Users will accept the pain that change brings if the benefits of that change outweigh the cost of it. If the cost/benefit ratio isn't favorable to the user, they will, quite understandably, resent the change.
Hyrum's Law:
"With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody."
I once worked at a place where we essentially were unable to fix bugs because it was a no-code tool so people would do all kinds of wacky things with the system.
The mandate was, as far as I can tell, to enshrine these former bugs into actual documented features. I wish I had seen this as a warning for how the place was ran but I also needed the money.
That was on top of people doing completely stupid things and abusing the systems we gave them in exchange for way too little money. It got to the point where the company was offering dedicated servers as an upsell because there were clients that were paying far too little money, in my opinion, for the amount of resources they were taking up.
The breaking point came when I got woken up at 3am two nights in a row by a client who was very obviously an Indian scam call center who was paying us something like $100 / mo to have a button that calls an engineer at any time. The problem was they had something like 7 layers of recursion through their app and each update was causing cascading updates and unsurprisingly was taxing the entire server causing updates to be slow and/or unreliable.
Maybe I just sucked at it but I told leadership we need to jack up prices on that button and kick these pretty obvious scammers off the platform. I left a few months later.
I was just thinking about that today as I was reading through some bug reports of the podcast app I'm using (Overcast). Someone was happy that a bug got fixed that caused an issue for them, they shared a screen recording and you can see that they use what looked like 300 playlists with filters to sort their podcasts into all kinds of buckets.
The developer of the software commented: "This is the most playlists I’ve ever seen. By far."
We’ve discovered with experience that every app which looks like a table and allows free text fields will be repurposed as a job applicant tracking tool, with uncontrolled discrimination comments.
And this is bad because it’s not GDPR-compliant (but fortunately, it’s not the fault of the software vendor, but of the data controller).
This is why I don't like semantic versioning. Semantic versioning only covers the "public API" but even the smallest "patch" change can result in a change in behaviour which has a big impact on the users.
This is covered in the spec. "Use your best judgement" is the answer. What's the other solution? Just give up and version you software sequentially/by timestamp?
This is why it is important to stratify your API promises.
Git is a good example of this, with "plumbing" commands meant for scripts and software and "porcelain" commands meant for a more comfortable user experience. Code is rigid while humans are flexible.
Only freeze APIs that have been proven in the field to be stable and necessary in the field by thousands of people.
reply