Software Enshittification (Bad UX) is on us too Ronald Loui Ronald Loui Ronald Loui Published May 29, 2026 + Follow Continuing my rush to get some ideas on a more persistently archived platform (LinkedIn is well indexed these days by search and LLM-AI). You never know what access remains to your home page and blogs when no one is around to pay the ISP and domain registration bills... and publication with peer-review seems so passe; are they really your peers? It's always risky taking time to write about computing issues. Theory and philosophy age well; performance and paradigm do not. By the time you suggest something real, someone has fixed it. A lot of the other systems publications are not real ideas. So yes, we do computing. A lot. And have new, good ideas. We just don't have time to talk about it much. Systems people traditionally let their builds do their talking. For example, my kvetching about scripting languages -- they were being ignored 1995-2005! -- and IEEE COMPUTER paper where i declared python a better first language for students than Java? Hard to read 20yrs later. Not because it was wrong, but because we won. Scripting has plenty of respect now. Maybe time to promote Java, esp as an AI-coding output language, as the pendulum swings too far to the other side. Actually, coding is changing so quickly, it would be a big gamble to write down predictions at this time. But there is a huge problem today worth complaining about, and worth putting one's name on the complaint. It's a problem we should be proud to crusade about: how horrible software and the user experience of software has become. It's been enshittified. That means it's bad, it didn't have to be this bad, and someone is to blame for it. Everyone knows this! We understand that it's the business practice of software firms these days to start out as a service, then exploit the users, turning the user into the product, then exploit the companies themselves. We understand that marketing has been out of control for so long it should just be taken behind the barn and shot. Logins for tracking. Roundtrips for logins. Menus for configuring popups. Configurations for controlling menus. Popups for confirming configurations. Hidden and moving targets for dismissing popups. We all see that legal CYA and last-minute security patches, notifications, and explicit acceptance requests are polluting the designs. Some of that is unavoidable. But a lot of that is due to technical people being lazy and lacking innovation, or using old paradigms that continue to be exploited. Doing things in low-EQ, unexamined, un-self-critical ways. It's time to look ourselves in the mirror and think about what we could be doing better. Business, marketing, legal, and security all will intrude. That's the nature of the beast. But a lot of things we need to fix are problems we create as software people. This is not an exhaustive list. It's a start of the conversation. It would take a semester's course to shed light on all of the sins. (That's the course we created for the Fall.) Think about some of these: WHERE IS THE KEYBOARD SHORTCUT? I understand you want to cater to novice users and get them onboard, up to speed, with the dumbest interfaces. That doesn't prevent you from making things easier for slightly more advanced users with keyboards. The mouse is still the enemy of the efficient person in a hurry. You can almost always support both. WHY ARE YOU MAKING UNNECESSARY ROUND TRIPS TO THE CLOUD? I understand that you are charged with exfiltrating user data and storing every keyclick and timestamp. You could still buffer them and send them in bunches. Would it kill you to put more data in each round trip to the server so one needn't wait so much so often? Remember how this behaves when the network connection slows down? WHY DO YOU ORGANIZE FOR YOUR SATISFACTION INSTEAD OF THE USER'S? Menus that are organized in alphabetical order are helpful; but would it be so wrong to put frequently used items also at the top? Or demote the rare and genuinely weird options? Why is your internal class hierarchy exposed as if that structuring is the best way for users to find what they want? PLEASE STOP FORCING AI AND NEW FEATURES ON US! Please stop adding so many features that the important, main features become hard to use. Please say no when managers insist that AI needs to be pushed onto users. They might override your nay, but at least you can be a voice for sanity. Most of it is worse with than without. At least try to determine whether users like it better before imposing. Management wants to brag about using AI; you say "you can't brag about what doesn't work!" HAVE THE GUTS TO DEFINE A GOOD DEFAULT BEHAVIOR! It's true that different users will want different defaults. Still, after someone chooses the same option 99x, don't you think the 100th should be the default? Should all choices be explicit and require cognitive engagement? Did anyone teach you compression through shorter paths for more frequent leaves? If not, go back to freshman data structures. WHY CEDE SO MUCH CONTROL TO THE NEXT LEVEL? I understand that your layer of abstraction is more likely to be used by the next layer, if you pass along maximum control. But you know they are going to abuse it. Why let the video take absolute control of the whole device? Why let the popup obscure all and capture all? Why can't the user see the URL, max the volume, dismiss the window while the ad is playing, or at least change the resolution of the ad so it doesn't swamp the processor? Really the programmable layer should define different ways to do things that are too often merged into a single library call, such as providing high priority vs low priority notification. Restrict who can use what and when. YOUR WAY OR THE HIGHWAY? Programmers have always thought users should take their way or stfu. There should be one right way of doing things, they say with a sniff. But that's just not true. Programmers should have to use their own software in low lighting, in moving cars, with pizza in one hand, with a splint of three fingers, with old tired eyes, with a mouse that is not tracking on a network that is enduring a lightning storm. Then maybe they won't insist on their one "true" way. Here's an idea: programmers should ask intended users what they think. All the time, not just in beta. WHY DO THESE ICONS MOVE AROUND? The more complex your dynamic interface assembly, the more likely the user has to wait for things to settle. The more often the click doesn't match the presentation. Is it really worth it to add so much that things are inherently brittle for the user? This is also true of change for change's sake, not just complexity. And when we acknowledge that user error is possible (often bad software, not just user mistake!), do we always have good solutions for backing out or backing up? WHY DOESN'T THIS ZOOM? Perhaps the most egregious example of lack of empathy for users is the inability to zoom parts of the interface. Panes that zoom but leave taskbars and status bars unviewable are common. Maps that zoom but annotations on them that do not are common. Unreadable charge level on phones. Zoom controls that require zoom to access. Logins and unlocks that require logins and unlocks to improve brightness and font size settings so the user can login or unlock. People really should be ashamed. We could go on and on and on. There is so much sinning in the software world, so much disregard of the user, so much low empathy masquerading as software tech progress. It's like we need a big old flood to wipe it all out and start over. Praying for big, big rain.