Skip Navigation

Beyond enshittification, why does tech oftentimes suck?

Sometimes I’ll run into a baffling issue with a tech product — be it headphones, Google apps like maps or its search features, Apple products, Spotify, other apps, and so on — and when I look for solutions online I sometimes discover this has been an issue for years. Sometimes for many many years.

These tech companies are sometimes ENORMOUS. How is it that these issues persist? Why do some things end up being so inefficient, unintuitive, or clunky? Why do I catch myself saying “oh my dear fucking lord” under my breath so often when I use tech?

Are there no employees who check forums? Does the architecture become so huge and messy that something seemingly simple is actually super hard to fix? Do these companies not have teams that test this stuff?

Why is it so pervasive? And why does some of it seem to be ignored for literal years? Sometimes even a decade!

Is it all due to enshittification? Do they trap us in as users and then stop giving a shit? Or is there more to it than that?

90 comments
  • Are there no employees who check forums? Does the architecture become so huge and messy that something seemingly simple is actually super hard to fix?

    👆I’m guessing this one is Microsoft. 👆

    Apple I cannot explain. They were the gold standard of both brilliant UI and UX, as well as best in class customer support. Now I’m tearing my hair out over seemingly simple things (like their horrendous predictive text in iOS), and I don’t even have any hair.

    • Apple is a strange beast. I was at their space ship HQ getting interviewed, and the guy kept pointing random facts about it. Like, this particular wood was harvested in the winter so that made it better, or that entire segments can be siloed off, or that the full height glass walls of the cafeteria can be opened on pivots, and there was just so much effort in making sure things worked just right.

      Meanwhile [this team] had to test software fixes for their product by provisioning ancient Mac mini's in a closet lab because they wanted to test the "full experience" and so every patch and update they had to do was painful and horribly tested. They all hated each other (which was obvious to me just from my time in their interviews, so it must have gotten really bad during the workday I imagine). Everyone seemed on edge all the time. Even the people in the hallways. But they were all super excited that they could order lattes from the iPads tethered to the break room countertops. And they had an apple orchard I guess. The idea of changing how they do what they do was completely unentertainable.

      The whole experience felt surreal, like I had stepped into the world according to The Onion.

    • Their UX and UI are their bread and butter, but as someone who has done extensive web app development for use on Safari browsers, if I had a nickel for every time their browser just IGNORED a standard, broke one that previously worked, or added new "features" that broke a standard, passing the responsibility of building a workaround down to individual developers... I'd have a few dollars anyway. I don't have much faith their code is all that good compared to average under the hood and the UI, and I think their reputation unjustly leads users to turn a blind eye or give them a pass when their stuff DOESN'T work or works BADLY. "They're Apple... everyone else seems happy. I must be doing something wrong."

      • Well i for one experience Apple rage multiple times a week, but I’m so entrenched in their ecosystem, i may never escape. Also there is no better alternative that would be quick and easy to setup and maintain.

    • Apple is a victim of always having to build the new thing, so there's never time or resources to fix the old things. They can sometimes do an end run around this by re-releasing the same thing over again and pretending it's new, but then the cycle just begins anew

  • 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.

  • This is somewhat outside the box but as tech becomes easier, a lot of people tend to become weaker at certain tech skills. An example of this is directory management. A lot of folks don't organize their file structures nowadays, relying heavily on the search bar to find everything.

  • Agile has poisoned software development to the point where it's fine to ship shit products that can be fixed post-release, which of course gives stakeholders and execs the reasons to tie performance and bonuses to shipping, as opposed to routine stable operations.

    I don't know if going back to Waterfall is the right fix, but something has to change. Shipping crap is the new normal. If programmers organize to fight for better wages and conditions, we absolutely must fight to hold management responsible for code quality. Get us additional hours for unit and behavioral testing, assessing and tackling technical debt, and so on.

  • 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.

  • Most tech sucks because it's closed source. Closed source products are typically made with "the least amount of work done to sell for the most amount of buck". So standards are only sloppily and partially implemented (or sometimes purposefully badly or differently to ensure incompatibility), and bugs after sale won't be fixed because why would they? They already have your money. Middle managers will work hard to ensure more money goes to advertising and marketing than to actual development.

    Then there is the embrace, expand, extinguish mentality (hello Microsoft!) to force customers to stay around their shitty products. Microsoft 365 and teams shit are perfect examples. The company I work at currently uses it and it's beyond garbage shit that is expensive as hell. Not an hour goes by without me being confronted by bad design, bugs, bugs, bugs, so many bugs... And it's all designed to ensure you stay in their little walled garden. I can't change this today, but I'm planning to be rid of it in about a year from now, fingers crossed.

    In my experience, open source software is fucking awesome because people built it to actually build something awesome. Standards are implemented to the letter, bugs are fixed, and it all works and looks awesome.

  • Everyone else has great points about complexity, but there is an additional issue which is the constant desire for change keeping products from being refined and perfected.

    Any product will have small changes that improve it, like reinforcing points of failure specific to that design. Let's take a kitchen knife, the kind chefs use. Some manufacturers have the exact same model produced for decades, with ever so slight variations on angles, handles, and so on as they refined design. Now they are high quality if they keep the production going, and that is something that has no moving parts! These knives continue to sell because they are used constantly, can break or be damaged, and new restaurants open all the time requiring a constant supply of knives.

    The home knife market does not have the same pressure for reliability because people don't use them all day every day like a chef. Instead, companies are constantly changing designs to sell new versions to the same over saturated market that prizes form over function. They change the handles slightly, make a change to the blade, and sometimes these changes make the knife worse but they can slap a 'new and improved' sticker on the label as long as something changed.

    The same thing happens with technology except complex systems have even more refinement needed while the companies are also trying to change things just to change them in the pursuit of the 'new and improved' market. Moving menus around, changing orders of things, making things look flashy are all side effects of tech being afraid of selling the same thing for an extended period of time because people want something new and shiny to replace what they had. Time and effort is spent on changing things, and it is hard to do bug fixes while also creating something new that might make a bunch of old bugs obsolete. Oh, and they will also be spending their time trying to patch critical vulnerabilities, because that might keep someone from buying their next thing.

    So all the effort going into changing things, often making them worse if they happened to stumble into a useful design already, and they put all of their focus on that change and vulnerabilities so they don't have time to fix usability issues or do the things that would make their product better because why bother as long as people are buying? Anything someone who is knowledgeable about being fixed is unlikely to be a priority because the regular user probably hasn't even noticed and they are the ones who are going to buy the next version. That is why things like bluetooth continues to suck, because it works well enough to sell more things and doing it right would take more effort. The handy feature that you used to like being removed? They felt it needed to change just to change and whoever provided input or feedback came up with this instead.

    Oh, and all of this was just talking about available time spent doing things but on top of that they want to spend as little as possible so they get the cheap parts that are made by companies who also make a product just good enough that they get more customers to buy their parts for as little cost to produce as possible.

    TLDR: market pressures favor changing things constantly which introduces more design flaws and capitalist pressures focus on revising designs to sell more and security flaws so as long as it sells it doesn't matter if it has shitty usability and minor flaws are never fixed

  • 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.

90 comments