How dare I polish and remove kludges from previous releases. 😆
Also, none of those kludges would have even been necessary if the project scope was properly defined from the start and the project manager didn’t let the users keep trickling in new requirements without also extending the deadline.
So yeah, how dare I go back and implement something the way it should have been done the first time?
Software developers are uniquely arrogant in their belief that they have a right to choose when the workers of entire industries or sometimes everyone in the world needs to re-train on the tools they use to do their jobs.
I’m a woodworker. Imagine if I walked into the shop one day to find my table saw replaced with one of those mutant sliding table European things because the manufacturer pushed an update. “We’ve replaced your tool with one that conforms to recently adopted industry norms, buzzwords and trendy design patterns we in the table saw industry have been peer pressuring each other into adopting. You may proceed to suckle upon our genitals in gratitude and worship.”
Meanwhile I’m losing money because the tool I rely on to run my business no longer functions how I was trained to use it. I have to tell my customers that their orders aren’t getting filled because I was visited by the saw fairy and instead of building their furniture for them I have to read manuals, learn how to safely use this thing, find where all the controls went, and then remake all the jigs and tooling I relied on for production and hopefully I can get back to doing actual work before they change it again according to their needs and not mine, on their schedule and not mine.
That’s what it’s like using software in the age of nightly updates or worse cloud-based solutions. You never know when your tools will change out from under you mid-project.
This is true. However, changes aren’t always bad. Messing up keybindings and just moving around stuff just so that it looks “cleaner” is the absolutely worst thing to do. If you decide to completely redesign your UI you should at least give Users the Opportunity to still use the old UI. This way new Users can start working with your new UI and the rest can, if they want, learn the new UI.
This is especially the Case when you redesign your UI in a way so that its more Intuitive to new Users.
The other response said it well enough, but I’ll go a step further.
MS made a tradition of moving functionality around in their OS for no other reason that I could glean than grouping things in an at least superficially comparable group and absolutely not where it was in the last version, merely so that certification from the previous version wouldn’t apply to the current one. They would do similar things with their Office application menus, in one version moving them around based on how often you used them (try doing phone support with that!), in another replacing them with little pictures that pretended they were related to their functionality, and again moving them around every version apparently for the sake of requiring recertification.
To top it all off, they would also not give you access to the old menuing systems. You could argue bloat, but that would be ignoring the massive piles of it they added for the sake of animating their new menus alone (which has value, to a degree).
I’m aware of some of the interesting bits of woodworking, as well. I can imagine the response if you told woodworkers that the only hammer/mallet they could use was a 16 oz claw hammer. And the reason we made all those different hammers is because they are the best option for the task they were designed for. You can get away with using a smaller set, especially if your workflow would require using some rarely enough that it isn’t worth adding in their storage and cost to be worth it, but a good woodworker will still be aware of those tools and be assessing their processes to determine if it’s time to expand their toolset.
And the difference between the physical world and the world of computer interfaces is you aren’t limited to just one. The open source world is particularly fond of including deprecated functionality because there are a lot of pieces working together and it will often take years to get everything updated, and you will never know when the last dependency is removed. Likewise with UIs. A lot of the time, a deprecated one can be kept around for those who can’t be bothered to learn the new one, but the cost of keeping the old version around for a few years is usually relatively low (and the developer can determine how much they are willing to have that cost be and do things to help make it stay within that limit). That’s no reason to leave the old version as the default, though.