See, you just set the bar so low. Being able to save isn’t working well, it’s just working. And I have held the title of QA in the past. It is in part how I know these things. And in the last 5 years or so, companies have been laying off QAs and telling devs to do the job. Real QA is hard. If it really mattered you would have multiple QA people per dev. But the ratio is always the other way. A QA can’t test the new feature and make sure ALL the old ones still work at the rate a dev can turn out code. Even keeping up on features 1 to 1 would be really challenging. We have automation to try and keep up with the old features, but that needs to be maintained as well. QA is always a case of good enough. And just like at Boeing, managment will discourage QAs from reporting everything they find that is wrong. Because they don’t want a paper trail of them closing the ticket as won’t be fixed. I’ve been to QA conferences and listened to plenty of seasoned QAs talk about the art of knowing what to report and what not to. And how to focus effort on what management will actually ok to get fixed. It’s a whole art for a reason. I was encouraged to shift out of that profession because my skills would get much better pay, and more stable jobs, in dev ops. And my job is sufficiently obscure to most management that I can actually care about the users of what I write more. But also I get to see more metrics that show how the software fails it’s users while still selling. I have even been asked to produce metrics that would misrepresent the how well the software works for use in upper level meetings. And I have heard many others say the same. Some have said that is even a requirement to be a principle engineer in bigger companies. Which is why I won’t take those jobs. The “good enough” I am witness/part of is bad enough, I don’t want to increase it anymore.

I haven’t been in the board room, but I have seen the department heads deflect by focusing on different numbers that do look good for unrelated reasons. Then blame the poor performance that was the result of a bad decision as an expected outcome of a long term decision. These people at those levels are pros at this. And the board cares about the stock price. Guess what, the stock price is not based on numbers, it is based on speculation. If the ceo can spin it, it doesn’t matter what it is. Like how layoffs often make the stock price go up. “We are reducing expenses to accelerate progress and be more nimble…” no they are firing people because they can’t manage to use those people to make money.
And I wish it was just me who has encountered these people… but sadly it isn’t. If you want an example. Look at Google, and read up on how the culture changed over time as it got bigger. It probably staved off the change longer than most and grew faster, so the number of employees that triggered the change is a lot higher than average, but it’s easy to read about.

Because I have worked with software for 30 years. When the employee is salaried, thier time costs nothing. I will say I have no experience with call centers. So those may be an exception. I believe the majority of computer use jobs are salary though.

Opinions like that are why software quality sucks. And why using software is so painful for most people. “I have to use a stroller to set my phone number on the UI.” “Sure, but uptime if 5 9’s, so it’s quality software”.

I have 30 years of work experience on both sides of the equation with companies of varying size. Once a company gets to somewhere between 500 and 1000 employees, the 2nd level managment starts to attract professionally ambitious people who prioritize thier career over the work to a more a more extreme degree. They never walk anything back. Every few years they will often replace a solution (even a working one) so that they can take credit for a major change. Anyway, you get enough of these and they start to back each other and squeeze out anyone who cares about the work. I have been told in one position that it doesn’t matter if you are right, you don’t say anything negative about person X’s plan. And many other people from other companies and such have echoed that over the years. Now small companies often avoid this. But most software targets the big companies for the big paydays. Of the ones I have worked at, some even openly admitted that financially they couldn’t justify fixing a user issue over a new feature that might sell more product because the user issues don’t often lead to churn, where as new features often seal a deal.

Uptime isn’t quality. Perf and reliability are easily faked with the right metrics. It’s trival to be considered working on PowerPoint without working well for the user

Uptime isn’t quality. Perf and reliability are easily faked with the right metrics. It’s trival to be considered working on PowerPoint without working well for the user.

Nor necessarily SaaS, but yes business tooling. Which is the vast majority of software if you include software businesses buy and make thier customers use. The incentive is for it to work, not for it to work well. The person who signed off on the purchase either will never know how bad it is because they don’t use it and are insulated by other staff from feedback, or because they are incentivesed to downplay and ignore complaints to make thier decision look good at their level in the company.

The key phrase was work well. You are saying they have a motive for it to work. Like not freeze up. I am saying they have no motive for it to work well. As in be user friendly or efficient or easy to use.

Quality is meaningless in SaaS. Only features matter.

Okay then the users aren’t subscribers, thier boss or the boss above that are. And that person doesn’t really care how hard it is to use. They care about the presentation they gave to other leadership about all the great features the software has. And if they drop it now, they look like a fool, so deal with it.

When the buyer isn’t the user (which is most of the time), no there isn’t. Competitors try to win with great sounding features and other marketing BS because that is all the director will see. The users are then left with the product that has all the bells and whistles, but is terrible at doing what actually needs to be done. And the competition is the same, so they don’t really have much choice. Bell’s and whistles are cheaper than making it work well.

Subscribers? 90 some odd % of SaaS is sold to businesses, not individuals.

No… the decision maker on the purchase is the user in that case. For software, the decision maker is almost always someone who won’t use it. Like ticket tracking software. The people filing the tickets, and the people responding are not the people who decided which ticket tracking software to buy.

No idea what you are talking about. Product companies are exactly what I am referring to. Some director signs off on the purchase, probably has never even seen the software. But he has seen the sales pitch. That is what the C suite of small companies are for, mingling with the decision makers.

Medical? Your funny. Healthcare software is the worst. There is a reason the stuff that matters is decades old. Cause the new stuff rarely works. And the rest… tell me again why I have to fill out the same forms year after year, and they never populate with my previous answers? Or why I have to tell them my 2 year old son isn’t menstruating or hasn’t stolen a car yet (on the same form no less). The software is so hard to use the providers have given up.

That’s a dream. The googles and such just buy them out and shut them down. There is always a bigger fish that spends more money preserving the status quo than making a product.

There is no financial motive for software to work well. The people who sign the check for it almost never have to use it.

My parents tell stories like these about the Pennsylvania coal mines from last century. They would just drop the person alive or dead on thier front porch with thier last paycheck pinned to them.

I did get a federal loan for college, so guess I must have enrolled without really knowing it. It was a really long time ago.