"Unless it's renders the product completely unusable, why spend money and fix it?"

Corporate mindset in a nutshell!

Because you're not paying extra for those problems to get fixed. And no, when you receive millions of forms per day, not every piece of feedback makes it back to someone to actually fix the issue. Especially when half those issues are "when I don't have internet I don't receive new emails".

Software, like hardware, is a balance between supply and demand. People would rather pay less for a phone crammed full of ads than pay for a service. Just look at YouTube for that one.

Also, those clunky interfaces are there for a reason. Maybe the interface element that's a lot better doesn't work in right to left languages. Maybe the information overload of too many buttons and labels made the old interface impossible to extend. Maybe the prettier solution doesn't work with screen readers or with the font size and colour cranked up for people with low vision. Maybe the feature redesign worked great but SomeCorp Tweaker Software will bluescreen the machine when it finds the word "checkbox" in a settings page for your mouse. Maybe the design team had a great idea but the feature needs to ship next week so whatever needs to happen to make that works happens, and the five other features planned for the month already eat up the rest of the dev team's time anyway.

But most of the time, things are suboptimal because there are seven teams of people working on features on the same screen/system/application and they need to make do.

If you have serious issues with some software, many companies will let you partner with them. In exchange for hundreds of thousands or millions, you can directly get support for your use cases, your workflow, and the stuff you need to get done, over the billions of other people that also need to use the software. And sometimes, that means your super duper expensive preference/feature/demand means someone else's workflow is entirely broken.

If you know what you want, there is a way out: going the way of open source and self hosted. Within a few years, you too will grow resentful of dozens of systems made by different people all interpreting standards differently and not working together. You have the power to fix each and every feature, bug, problem, and design flaw, but none of the time or the detailed knowledge. You don't have the money to pay experts, and even if you did, what they do may not entirely suit you either. Trying to fix everything will drive you absolutely mad. And that's why companies and people often don't try for perfection.

This is a topic that could be a novel for how much there is to consider, but in the end it comes down to resources and companies trying to choose what it best for the company overall. For a company to do anything, they are giving up many other things they could be doing instead. Whether it is limited budgets, limited personnel, or company priorities every decision made is always a tradeoff that means you aren't doing something else.

Most companies prioritize releasing new product so they can start getting revenue from it as soon as possible. A new product has the largest potential market, and thus makes shareholders happy to see revenue coming in. The sales from a new product are the easiest ones in most product's lifecycle. Additionally. releasing new products helps keep you ahead of competitors. So ongoing maintenance work is de-prioritized over working on new things.

The goal of testing is to simulate potential use cases of a product and ensure that it will work as expected when the customer has the product in their hands. It is impossible to fully test a product in a finite amount of time, so tests are created that expose flaws within a reasonable search space of the expected uses. If an issue is found then it needs to be evaluated about whether it is worth fixing and when. There are many factors that affect this, for example:

• How much would it cost to fix?
• How much time would it take to fix?
• Does it need to be fixed for launch or can it be a running change?
• How many customers are actually going to see the issue? Is it just a small annoyance for them or will it cause returns/RMAs?
• Is it within the expected use case of the product?
• Can we mitigate it in software/firmware instead of changing hardware?
• Is it a compliance/regulatory issue?
• Would this bring in new customers for the product?
• Was this done a specific way for a reason?

Unfortunately, after considering all this the result is often that it isn't worth the effort to fix something, but it is considered.

There's the compounding issue that something that seems simple on the surface, say, pairing a pair of bluetooth headphones, is a convoluted mess of super-complicated shit on a technical level.

And to even handle that, the engineer making the app that handles these does not know about how to sync an L and an R headpiece. And the person who knows about that does not know how to establish contact via bluetooth. Etc. It's layers upon layers upon layers of tricky technical stuff. Each of which has the ability to propagate buggy behavior both up and down the layers. And each engineer probably cannot easily fix the other layers (they're not theirs), so they work around the bugs. Over time this adds an insane amount of complexity to the code as hundreds of these tiny adjustments are spread everywhere.

Tech companies only care about making money. If people continue to buy their half-effort products, then they'll keep making it.

On the other hand, open-source (hardware or software) is designed for maximum longevity.

Unfortunately, the wrong people have unlimited resources when it comes to making our tech products.

Something I've noticed in places I've work that aren't small, whoever has talent gets promoted into being half the time in meetings at best, and at worse into managing teams and working by Outlook.

rush to market mostly

I think that manufacturers of tech products test their products only with a few standard configurations - but in reality there are too many possible combinations of different configurations:

Take a bluetooth mouse for example. Generally, it connects to a computer and it works. Now imagine that you have a different configuration - a logicboard in your laptop that has not been tested by the manucacturer of the mouse or an obscure model of the bluetooth reciever, that also hasn't been tested to work with that mouse. Your mouse works well in the beginning, but disconnects at random times. You can't pinpoint the issue, and when you are looking for help online, nobody seems to have the same problems with that mouse.

In this case, said mouse sucks, because it doesn't function reliably. A different person with a different configuration of their computer (different logicboard, different model of the bluetooth unit) might have no problems at all with the same mouse.

enshitification is based on the ease of moving profits from users to creators then from creators to shareholders in a digital service economy all the while degrading the service for the users and then the creators as the profit fulcrum.

so enshitification might be a different thing than the reality around manufacturing items in an international environment which requires design decisions that later require revising because not all materials are available from everyone in the way a design is called for. and finding people that can assemble things while receiving a wage that they can live so that a company can make a profit requires compromises. and that is just two tiny points in not including shipping and workspaces and insurance et cetera

it is hard, yo. in a not a one part is inconceivable hard but in a it gets complicated pretty quickly type of hard.

Speaking as a software engineer, it's usually a combination of things.

The root of all evil is that yes, fixing that thing doesn't just take one hour, as it should, but rather a few days. This is mostly preventable by having sufficient automated tests, high code quality and frequent releases, but it's a lot of work to keep up with. And you really need management to not pressure early feature delivery, because then devs will skip doing necessary work to keep up this high feature-delivery velocity.

Well, and as soon as such a small fix has a chance of taking more than a day or so, then you kind of need to talk to management, whether this should be done.
Which means probably another day or so of just talking about it, and a good chance of them saying we'll do it after we've delivered this extremely important feature, which usually means 'never', because there is always another extremely important feature.

I worked at Google for over a decade. The issue isn't that the engineers are unaware or unable. Time and time and time again there would be some new product or feature released for internal testing, it would be a complete disaster, bugs would be filed with tens of thousands of votes begging not to release it, and Memegen would go nuts. And all the feedback would be ignored and it would ship anyway.

Upper management just doesn't care. Reputational damage isn't something they understand. The company is run by professional management consultants whose main expertise is gaslighting. And the layers and layers of people in the middle who don't actually contribute any value have to constantly generate something to go into the constant cycle of performance reviews and promotion attempts, so they mess with everything, re-org, cancel projects, move teams around, duplicate work, compete with each other, and generally make life hell for everyone under them. It's surprising anything gets done at all, but what does moves at a snail's pace compared to the outside world. Not for lack of effort, the whole system is designed so you have to work 100 times harder than necessary and it feels like an accomplishment when you've spent a year adding a single checkbox to a UI.

I may have gone on a slight tangent there.

Sometimes it's a solution in search of a problem. Usually that'll be some startup that really wants Google (or somebody) to either buy them out or shovel millions of venture capital money at them. VC that would be better used for anything that housing homeless people, feeding the hungry, or hell just burning to stay warm.

It's a young field and we're still entrenched in the consequences of the sort of mistakes that, in a few hundred years, will become "those silly things people used to do because they didn't know better".

Daily reminder that the web is a mess of corpo bullshit piled on top of 90s tech and most OSes currently in use are culturally from the early 80s.

We tend to forget that all of that is to support people. Tech shouldn’t be an end goal, merely one of the ways to achieve it. And not always the best one at that.

Arrogance. They're attitude is basically "we built it, so it's golden. If you can't understand why we did it this way, then put the device down and flip burgers".

I saw this starting around the year 2005. I spoke out about it and told people stop buying /using products that aren't logical and easy to use. If it takes a Google search and a YouTube video to figure out how to use it, then it was built wrong. Return the product and get a better one. No one listened to me. We have what we have.

It sucks and it will only get worse. People will not change. People will keep buying shit products, then bitch that the products suck. Instead of returning the crap, they will keep it. Because they keep it the companies have zero reason to change.

The difficulty of keeping something working scales exponentially as its complexity grows. Something of 1x complexity take 1y effort, but 2x complex is 10y effort, 3x complex is 100y, on and on.

Phones/computers/apps are at hilarious levels of complex now, and even 100k people running flat out can barely maintain the illusion that they "just work." Add enshittification heaping its intentionally garbage experience onto the unintentional garbage experience that is modern computing, and it's just gotten stupid.

Apple

I’ve submitted at least 8 bug reports to them since Oct 2023 (and also many suggestions) through their feedback app. No response to any of them until now. The only closed bugs I closed myself because the problem went away in an update.

I’m pretty sure they don’t have any bug triager whatsoever.

I’ll keep doing it out of spite and because it’s what I do for open-source as well, but I’m really not sure if it has any effect at all.

Why is it so pervasive? And why does some of it seem to be ignored for literal years?

Considering that you know that these problems have not yet been fixed, you must still be using these products despite these problems not yet being fixed and there's your answer: What would the motivation be to fix problems that aren't severe enough to make you stop using the product?

Programmers don't get given the leeway to make the work they do of good quality if it doesn't directly lead to more profit

People who weren't interested in tech found out they could make a lot of money in the field. The scene went from nerds who were passionate about the field to people who would be just as (un)interested in being doctors and lawyers. The vibrancy is gone.

Source: tech-excited nerd who got into the industry in the late aughts.

Leveraging technology is a lever of power. Whenever you use technology, you are acting in a submissive manner and that will be used to exploit you.

Most people tend to buy the imperfect cheap product rather than the better, more expensive product.

If we refused to buy crap, they wouldn't make it. If we refused to buy it, they couldn't make it.

They sell us crap because collectively we prefer it.

Aside from the effort required others have mentioned, there's also an effect of capitalism.

For a lot of their tech, they have a near-monopoly or at least a very large market share. Take windows from Microsoft. What motivation would they have to fix bugs which impact even 5-10% of their userbase? Their only competition is linux with its' around 4(?)% market share and osx which requires expensive hardware. Not fixing the bug just makes people annoyed, but 90% won't leave because they can't. As long as it doesn't impact enterprise contracts it's not worth it to fix it because the time spent doing that is a loss for shareholders, meanwhile new features which can collect data (like copilot for example) that can be sold generate money.

I'm sure even the devs in most places want to make better products and fight management to give them more time to deliver features so they can be better quality - but it's an exhausting sharp uphill battle which never ends, and at the end of the day the person who made broken feature with data collector 9000 built in will probably get the promotion while the person who fixed 800 5+ year old bugs gets a shout-out on a zoom call.