That’s where you need people like me who give a fuck about nothing but customer experience and if my employer manages to make a buck, good for them. My employer is generally just a middle man who siphons money out of both our pockets. And makes me fill out a second, useless timesheet while you’re paying me to work.
Jokes on me though because I’ve been out of work for 3 months, so take my suggestion of fuck your employer with a grain of salt.
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.
I would love to see exactly how many people dropped Adobe after the latest drama, I would bet it would look exactly like the Netflix micro dip after shutting down password sharing.
Sonos has pissed me off. After the latest update, the app cannot locate the speakers in any of my rooms. The TV speakers still work with a signal from the TV, but the speakers in all other rooms basically cannot be used.
I’ve factory reset them, set them up in the app, and as soon as that is done, they disappear from the app again.
They worked fine for years, then this bullshit. I’m researching a home theater setup that doesn’t use Sonos and am planning on selling it all once I’ve found replacements.
It feels like I don’t own the very expensive hardware that I have bought. I guess since they are software controlled, I really dont.
I don’t really get this point. Of course there’s a financial motive for a lot of software to work well. There are many niches of software that are competitive, so there’s a very clear incentive to make your product work better than the competition.
Of course there are cases in which there’s a de-facto monopoly or customers are locked in to a particular offering for whatever reason, but it’s not like that applies to all software.
Software just has to be good enough that people put up with it. Once you get users on the system, you make it difficult to move your data out which acts as a lock in mechanism. The company that can make a minimally usable product that people are willing to put up with will typically beat one making a really good product that takes longer to get to market.
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.
So you’re talking about SaaS / business tooling then? Again though, that’s just one of many segments of software, which was my point.
Also, even in that market it’s just not true to say that there’s no incentive for it to work well. If some new business tool gets deployed and the workforce has problems with it to the point of measurable inefficiency, of course that can lead to a different tool being chosen. It’s even pretty common practice for large companies to reach out to previous users of a given product through consultancy networks or whatever to assess viability before committing to anything.
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.
Depends on business model. Saas - quality is very important. Non-profit insurance/bureaucratic type - they’ll burn millions to hire plenty of QA then treat them like shit, ignore them, and push trash software all day
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.
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”.
Lol, saying uptime is needed for quality of why software quality sucks? What? Uptime is part of quality, it is not the sole determination of quality. You seem to be purposefully misunderstanding that concept.
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 indicates reliability. Reliability is a factor of quality. A quality product has a high uptime. What good is a solution that doesn’t work 20% of the time? That’s exactly how you lose clients. Why do SLAs cover topics like five 9s uptime if they don’t matter and can be faked? This makes no sense.
You said quality doesn’t matter, only features. Ok, what happens when those features only work 10% of the time? It doesn’t matter as long as it has the feature? This is nonsense. I mean why does QA even exist then, what is the point of wasting spend on a team that only worries about quality, they are literally called Quality Assurance. Why do companies have those if quality doesn’t matter, why not just hire more eng to pump out features. Again, this makes no sense. Anyone who works in software would know the role of QA and why it’s important. You claim to work in tech, but seem to not understand the value of QA which makes me suspicious, that or you’ve just been a frontline dev and never had to worry about these aspects of management and the entire SDLC. I mean why is tracking defects a norm in software dev if quality doesn’t matter? Your whole stance just makes no sense.
It’s trival to be considered working on PowerPoint without working well for the user
No it’s not trival. What if “not working well” means you can’t save or type? Not working well means not working as intended, which means it does not satisfy the need that it was built to fill. You can have the feature to save, but if it only works half the time then according to you that’s fine. You might lose your work, but the feature is there, who cares about the quality of the feature… If it only saves sometimes or corrupts your file, those are just quality issues that no one cares about, they are “trivial?”
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’m setting a new low sure, and you’re moving the goal posts. What “well” means is incredibly subjective.
You worked in QA, cool, and I’ve manage the entire R&D org of a nation wide company, including all of QA.
Your saying that since companies don’t invest in it enough it doesn’t matter at all? Why do they even invest at all then, if it truly doesn’t matter.
Yes a QA can test old features and keep up with new ones. WTF, have you never heard of a regression test suite? And you worked in QA? ok. Maybe acknowledging AQA is an entire field might solve that already solved problem.
You did a whole lot of complaining and non relevant stories but never answered any questions I’ve been asking you across multiple comments…
What goal post have I moved. My initial comment could have said work well for the user. But the second sentence implied that pretty clearly. And I am still saying it now.
And great for you. You probably drank the kool-aid to get that position, so you feel the need to claim carry water for the illusion that upper management always try to project. I mean, you might be the exception, and truely believe in the things you say. Maybe you even work for one of the rare companies where it is true. But the vast majority of people working in the field that I have talked to have said that just isn’t how it is most places. Many said it used to be, when their company was small… but that it changed.
And yes I wrote regression tests. And I worked hard to maintain them while writing tests on features. But with a 5 to 1 ratio of devs to QA, it wasn’t possible to not cut corners. A year after I changed jobs I found out they had lowered the bar for releasing to 55% passing of the regression tests. I never had the tools to make them able to resist change as they had no one owning the automation tools. The next guy just didn’t care as much. The job I moved to was qa automation so the qa’s were my customers. I did my best there to give them automation that would reduce maintenance costs. But we weren’t allowed to buy anything, we had to write it all. And back then open-source wasn’t what it is today. So the story was the same, cut corners on testing. And of course the age old quote… “why is QA slowing down our release process”. Not why are the devs writing poor code. The devs weren’t bad either, but they were pressed to get features out fast.
As for why do they invest in it at all. Optics is a big part of it. But also to help maintain that low bar you spoke of. The moment industry trends started touting the Swiss army knife developer who could do it all including testing, they dropped qa teams like a bad habit. Presentations were given on how too much testing was bad, and less tests were better… that pendulum swings back and forth every decade or so. Because quality drops below the low bar, and the same exec who got a promotion for getting rid of the qa team at his last job 7 years ago, gets accolades for bringing it back in his new job.
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.
They do care, %100 they care. If you take longer to do task X because the SaaS solution crashes or is unavailable, or causes issues in finance, or a dozen other things then the company will very much care. I literally work at a SaaS company and hear complaints from clients. Money is all that matters, if your solution isn’t as good at making/saving them money as another solution, you get dropped. And reliability is a big part of that. A solution that frequently has issues is not a money-making/saving system that can be relied on.
It’s not about looking like a fool; it’s about what your P&L looks like. That’s what actually matters. Say you made a nice slide deck about product X and got buy-in. Walking that back is MUCH easier to do than having to justify a hit to your P&L.
What experience do you have to be making these claims?
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.
You seem to be basing how the entire industry works on some people you’ve encountered who want to climb the ladder. Again, when you stand in front of a board and have to justify your EBITDA, it doesn’t matter how good your PowerPoint slide was. They don’t have to walk it back, the P&L is numbers, they have to justify those numbers or deal with not hitting budget. A company runs off numbers not initiatives people want to push.
You seem to be ignoring the fact that you have to report metrics to investors. Spend, rev, output, etc. And a poor SaaS solution that has poor quality negatively impacts those numbers. Numbers don’t lie, no matter how much spin you put on them. You say you have 30 years of experience both consuming and delivering SaaS solutions but seem to ignore that you have defended your P&L and your performance, all numbers, not office politics. Investors only care about money, dollars and cents, numbers. So what happens when solution X that Bob pushed and no one can talk bad about tanks your topline, or your EBITDA? Then what? You tell the board not to say anything bad about it? That just doesn’t make sense.
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.
There is no financial motive for software to work well. The people who sign the check for it almost never have to use it.
That’s where you need people like me who give a fuck about nothing but customer experience and if my employer manages to make a buck, good for them. My employer is generally just a middle man who siphons money out of both our pockets. And makes me fill out a second, useless timesheet while you’re paying me to work.
Jokes on me though because I’ve been out of work for 3 months, so take my suggestion of fuck your employer with a grain of salt.
If they do a bad enough job they’ll create a niche for a competitor to fill.
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.
I would love to see exactly how many people dropped Adobe after the latest drama, I would bet it would look exactly like the Netflix micro dip after shutting down password sharing.
Found the Sonos employee.
Sonos has pissed me off. After the latest update, the app cannot locate the speakers in any of my rooms. The TV speakers still work with a signal from the TV, but the speakers in all other rooms basically cannot be used.
I’ve factory reset them, set them up in the app, and as soon as that is done, they disappear from the app again.
They worked fine for years, then this bullshit. I’m researching a home theater setup that doesn’t use Sonos and am planning on selling it all once I’ve found replacements.
It feels like I don’t own the very expensive hardware that I have bought. I guess since they are software controlled, I really dont.
I don’t really get this point. Of course there’s a financial motive for a lot of software to work well. There are many niches of software that are competitive, so there’s a very clear incentive to make your product work better than the competition.
Of course there are cases in which there’s a de-facto monopoly or customers are locked in to a particular offering for whatever reason, but it’s not like that applies to all software.
Software just has to be good enough that people put up with it. Once you get users on the system, you make it difficult to move your data out which acts as a lock in mechanism. The company that can make a minimally usable product that people are willing to put up with will typically beat one making a really good product that takes longer to get to market.
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.
So you’re talking about SaaS / business tooling then? Again though, that’s just one of many segments of software, which was my point.
Also, even in that market it’s just not true to say that there’s no incentive for it to work well. If some new business tool gets deployed and the workforce has problems with it to the point of measurable inefficiency, of course that can lead to a different tool being chosen. It’s even pretty common practice for large companies to reach out to previous users of a given product through consultancy networks or whatever to assess viability before committing to anything.
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.
Depends on business model. Saas - quality is very important. Non-profit insurance/bureaucratic type - they’ll burn millions to hire plenty of QA then treat them like shit, ignore them, and push trash software all day
Quality is meaningless in SaaS. Only features matter.
Yeah no. Performance, reliability, uptime are huge.
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 is quality. It’s why uptime is in SLAs. A quality product isn’t down half the time.
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”.
Lol, saying uptime is needed for quality of why software quality sucks? What? Uptime is part of quality, it is not the sole determination of quality. You seem to be purposefully misunderstanding that concept.
False. Have a 70% up time and let me know how many clients you have left.
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 indicates reliability. Reliability is a factor of quality. A quality product has a high uptime. What good is a solution that doesn’t work 20% of the time? That’s exactly how you lose clients. Why do SLAs cover topics like five 9s uptime if they don’t matter and can be faked? This makes no sense.
You said quality doesn’t matter, only features. Ok, what happens when those features only work 10% of the time? It doesn’t matter as long as it has the feature? This is nonsense. I mean why does QA even exist then, what is the point of wasting spend on a team that only worries about quality, they are literally called Quality Assurance. Why do companies have those if quality doesn’t matter, why not just hire more eng to pump out features. Again, this makes no sense. Anyone who works in software would know the role of QA and why it’s important. You claim to work in tech, but seem to not understand the value of QA which makes me suspicious, that or you’ve just been a frontline dev and never had to worry about these aspects of management and the entire SDLC. I mean why is tracking defects a norm in software dev if quality doesn’t matter? Your whole stance just makes no sense.
No it’s not trival. What if “not working well” means you can’t save or type? Not working well means not working as intended, which means it does not satisfy the need that it was built to fill. You can have the feature to save, but if it only works half the time then according to you that’s fine. You might lose your work, but the feature is there, who cares about the quality of the feature… If it only saves sometimes or corrupts your file, those are just quality issues that no one cares about, they are “trivial?”
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’m setting a new low sure, and you’re moving the goal posts. What “well” means is incredibly subjective.
You worked in QA, cool, and I’ve manage the entire R&D org of a nation wide company, including all of QA.
Your saying that since companies don’t invest in it enough it doesn’t matter at all? Why do they even invest at all then, if it truly doesn’t matter.
Yes a QA can test old features and keep up with new ones. WTF, have you never heard of a regression test suite? And you worked in QA? ok. Maybe acknowledging AQA is an entire field might solve that already solved problem.
You did a whole lot of complaining and non relevant stories but never answered any questions I’ve been asking you across multiple comments…
What goal post have I moved. My initial comment could have said work well for the user. But the second sentence implied that pretty clearly. And I am still saying it now. And great for you. You probably drank the kool-aid to get that position, so you feel the need to claim carry water for the illusion that upper management always try to project. I mean, you might be the exception, and truely believe in the things you say. Maybe you even work for one of the rare companies where it is true. But the vast majority of people working in the field that I have talked to have said that just isn’t how it is most places. Many said it used to be, when their company was small… but that it changed.
And yes I wrote regression tests. And I worked hard to maintain them while writing tests on features. But with a 5 to 1 ratio of devs to QA, it wasn’t possible to not cut corners. A year after I changed jobs I found out they had lowered the bar for releasing to 55% passing of the regression tests. I never had the tools to make them able to resist change as they had no one owning the automation tools. The next guy just didn’t care as much. The job I moved to was qa automation so the qa’s were my customers. I did my best there to give them automation that would reduce maintenance costs. But we weren’t allowed to buy anything, we had to write it all. And back then open-source wasn’t what it is today. So the story was the same, cut corners on testing. And of course the age old quote… “why is QA slowing down our release process”. Not why are the devs writing poor code. The devs weren’t bad either, but they were pressed to get features out fast.
As for why do they invest in it at all. Optics is a big part of it. But also to help maintain that low bar you spoke of. The moment industry trends started touting the Swiss army knife developer who could do it all including testing, they dropped qa teams like a bad habit. Presentations were given on how too much testing was bad, and less tests were better… that pendulum swings back and forth every decade or so. Because quality drops below the low bar, and the same exec who got a promotion for getting rid of the qa team at his last job 7 years ago, gets accolades for bringing it back in his new job.
I mean, no? If you are at a SaaS company the software working well is the most important aspect. Loss of quality leads to loss of subscribers.
Subscribers? 90 some odd % of SaaS is sold to businesses, not individuals.
Yah, clients are subscribers
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.
They do care, %100 they care. If you take longer to do task X because the SaaS solution crashes or is unavailable, or causes issues in finance, or a dozen other things then the company will very much care. I literally work at a SaaS company and hear complaints from clients. Money is all that matters, if your solution isn’t as good at making/saving them money as another solution, you get dropped. And reliability is a big part of that. A solution that frequently has issues is not a money-making/saving system that can be relied on.
It’s not about looking like a fool; it’s about what your P&L looks like. That’s what actually matters. Say you made a nice slide deck about product X and got buy-in. Walking that back is MUCH easier to do than having to justify a hit to your P&L.
What experience do you have to be making these claims?
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.
You seem to be basing how the entire industry works on some people you’ve encountered who want to climb the ladder. Again, when you stand in front of a board and have to justify your EBITDA, it doesn’t matter how good your PowerPoint slide was. They don’t have to walk it back, the P&L is numbers, they have to justify those numbers or deal with not hitting budget. A company runs off numbers not initiatives people want to push.
You seem to be ignoring the fact that you have to report metrics to investors. Spend, rev, output, etc. And a poor SaaS solution that has poor quality negatively impacts those numbers. Numbers don’t lie, no matter how much spin you put on them. You say you have 30 years of experience both consuming and delivering SaaS solutions but seem to ignore that you have defended your P&L and your performance, all numbers, not office politics. Investors only care about money, dollars and cents, numbers. So what happens when solution X that Bob pushed and no one can talk bad about tanks your topline, or your EBITDA? Then what? You tell the board not to say anything bad about it? That just doesn’t make sense.
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.