> "We spent x weeks working so users with low memory space can update"

But it's the other way around! That's the whole point. Every app starts out small. Apps don't grow unless you add complexity to them. It's much less work to do something simple than doing it overly complex. We see this all the time.

The question to ask should instead be: How can it be that "We spent x weeks working on increasing complexity" is not completely unsellable, if all your users want to do is pay their bills?

Now, reality is never that simple and users constantly ask for new features, that much is true. But why can we as an industry never listen to all those users who don't want new features?

It used to be completely normal to identify a need, sketch out the most appropriate funcitonality to solve that need, and them implement it. Then the core functionality is done. The software can continue to be developed around that functionality, but the core is fixed because the problem domain is well described.

No software is allowed to fit the problem domain anymore. It's just a constant pile of features upon features, to keep a legion of product designers, user experience managers, product owners, and an army of developers busy every day with no end in sight. The only break from the treadmill is the occasional product redesign, and if you can't afford that this increment then you can always change the frontend framework. Whatever happened to decent problem modelling and when you're done, you're done? Optimizing what we got instead of expanding it?

Watch a Dune movie some time and replace "the spice must flow" with "the features must flow".

Making money is the task at hand, and orgs make money these days by monetizing users and not treating them well. Their status as a customer is taken for granted - because where are you going to go? All the other guys are as bad or worse.

The Chase app I use is 298mb.

To an extent, I think this is still on the dev. Don't declare your feature done when the bare minimum of works on my machine when I squint is done. One of my first managers taught me this lesson, the feature isn't done when you're done coding, it's done when you've jumped through all the other hoops too, and it's actually live and ready to use. That includes stuff like tests, review, qa, and in this context, making sure it's performant. Agreeing to cut corners to meet an unrealistic deadline very much is on the dev.

I agree 100% as I wrote in my final sentence, we're just part of the picture.

most devs complain about management tying their hands but more often than not they have a great deal of control over the tech, libraries, or frameworks adopted. these are the biggest culprits behind crap software.

if adding a new feature or button significantly slows your app, and you had a role in the architecture, you have no one to blame but yourself

While I agree with you that a lot of sub-par technical people are relegated to the role of QA, just because you haven't seen one proper QA person in your life, doesn't mean they don't exist.

Have you ever thought to ask if the company you're working for puts their money where their mouth is, when it comes to quality? If they did, how are these people getting hired in the first place? What responsibility falls on the engineers who interviewed these folks? Does your reporting structure reward people who raise problems, or punish them? Who do your QA people report to? And please don't say the head of development, who is responsible for deliverable dates.

The best QA people I've ever known had such a good grasp on the market and customer needs that they were, in fact, product managers. Sounds like you've probably had a similar experience.

Don't throw the baby out with the bathwater. There's plenty to learn from Statistical Process Control and Deming, etc.

I've worked on more projects without a requirements specification, than with one. Without a competent PM, how will QA people even test? I guess they can intuit what the product actually needs to do, but then there's ambiguity. The reality is that someone (product) needs to document exactly what the product needs to do and how it must operate, in no uncertain terms. Even with a spec, it's often still quite ambiguous. I honestly see these problems as organizational, so when you slag on the QA folks, I get a little miffed.

I've caught plenty of bugs at review time, that could have been caught by some basic cursory testing on the developer's part. Mistakes happen. Even QA people make mistakes, we're all human after all. Does placing the blame directly on the QA people really help you? Imagine if you started asking questions about your development process, and where things could have gone wrong? The fish rots from the head, and often times bad practices are (explicitly or implicitly) rewarded by management, because they result in faster iterations, shorter delivery time, but something is definitely being lost here.

Sorry if my rant is slightly inflammatory, this is coming from a QA person who has seen a lot of these failures in practice, so I feel the need to defend the position a bit.