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?
Hrm, I would argue that if your update gets in the way of productivity on the user side, then it’s actually worse, not better.
Sure, in a vacuum it might be superior, but that is now what is happening.
We used to rail against our users always wanting an Excel like view for everything, but when you observe them working to understand their work flow it makes sense. They use excel the other 75%of the day, we’re the one breaking their mental flow and ruining their productivity.
Just because someone got used to walking around on their knuckles doesn’t mean walking upright isn’t easier and better overall. Sure, it will be difficult, it will be uncomfortable, and they’ll have to get used to it before they see any improvement, but once they get past those hurdles even they will be amazed at how fast walking upright can be. And in the meantime, no one else who already has a tendency to walk upright will have to go through the pain and inefficiency of walking on their knuckles.
These people don’t get to pick whether they use Excel, either. They have to, they just want to get their job done and go home, too.
They don’t get paid to walk upright, basically. So why do it just so someone else can buy another yacht?
You seem very defensive of the workers. That’s cool, I’m one of them.
Good workers will do better with the right tool. Bad workers, those who are resistant to change and are unwilling to learn, will never do better. So why cater to the bad workers? Now catering to the bad workers makes sense if the job is so basic that virtually no training is required, and bad workers need to eat, too. But saying we should all crawl because they don’t want to run is absurd.
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.
It is if you don’t get pay to run, getting anywhere faster doesn’t help you at all, and it costs more energy. And you gain nothing from it. That’s my point.
Some people don’t have time to learn new workflows at their job. Their workload is maxed out with the workflow they currently have and while their boss may understand they need time to learn a new workflow, the bean counters up the chain won’t. Maybe their replacements will get trained on the changes you made but the current ones are fucked.