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.
And if the business needs aren’t met, said businesses will go to another SaaS company that promises them a better, brighter future.
The user might not be the subscriber, but the user being less productive because the software is getting in their way, will irritate the subscriber.
I know a SaaS company that put thousands upon thousands of engineering hours into making small (and sometimes large) optimizations over their overall crappy architecture so their enterprise customers (and I’m talking ~6 out of the top 10 largest companies in one industry in the US) wouldn’t leave them for a solution that doesn’t freeze up for all users in a company when one user runs a report. Each company ran in a silo of their own, but for the bigger ones… I’m not going to give exact numbers, but if you give every user a total of half an hour of unnecessary delays per day, that’s like 500 hours of wasted time per day per 1000 employees. Said employees were performing extremely overpriced services, so 500 hours of wasted time per day might be something like 100k income lost per day. Not an insignificant number even for billion dollar companies.
I’ve since left the company for greener pastures and I hear the new management sucks, but the old one for sure knew that they were going to lose their huge ass clients over performance issues and bugs.
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.
Ok, well really splitting hairs on what “working well” means but ok. Why do UX designers exist? I mean if you have a bad UI that takes a user 10 min to do something that can be done in 10 seconds in another solution, you lose. Time is money. Anyone who has ever been in magament knows it’s all about cost vs output. If a call center employee can handle 2x more cases with another solution due to a better UX, they will move to that.
You are saying efficiency doesn’t matter, which is just %100 false. A more efficient solution makes/saves more money. It saves time, which is also money and improves agility of the team. How can you say with a straight face that a business doesn’t care about efficiency of it’s workers…
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.
Ugh, wrong again. Time is money. People have limited bandwidth and output, you want to get at much output as you can for the salary spend while realizing each person has a finite output. You keep saying things like “time costs nothing” and “quality doesn’t matter” which are just completely wrong and if true would upend the industry.
Also I’ve been in software for just over 20, the last 4 of those as a CTO. Since you seem to keep bringing up your credentials for some reason.
In one thread someone questioned if I even work in tech. So I started mentioning my experience to back up my claims. My current CTO fully admits that we have to cut corners and deliver features to win customers. That why I work for him. He is honest about it. And he is not new at it either.
As for time is money… take a person working 40 hours a week, and replace thier tool with a cheaper lower quality tool, then tell them to make it work. They start working 44 hours a week. You saved money and got the same result. Awards for you. And a lot of people will do the extra work, because they care about the work. As a bonus, the people who won’t work extra leave. Now you have a self selecting group of people who will work longer for the same price. And those tend to be the people who won’t leave for various reasons. So now you can even not backfill some of the ones who left, and tell the ones who stayed to cover the slack. Wow, even more money saved. I’ve seen that happen at a company with billions in revenue and great profits. But the shareholders demand growth, so if they can’t sell more, they must cut expenses to grow profits.
I think it’s equally true for product companies. Do you know how hard it is to get a company to prioritize bug fixing over feature work? Shy of a user revolt, or a friend of the CEO reporting an issue, bugs are almost always second priority or lower.
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.
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.
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
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.
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.
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.
And if the business needs aren’t met, said businesses will go to another SaaS company that promises them a better, brighter future.
The user might not be the subscriber, but the user being less productive because the software is getting in their way, will irritate the subscriber.
I know a SaaS company that put thousands upon thousands of engineering hours into making small (and sometimes large) optimizations over their overall crappy architecture so their enterprise customers (and I’m talking ~6 out of the top 10 largest companies in one industry in the US) wouldn’t leave them for a solution that doesn’t freeze up for all users in a company when one user runs a report. Each company ran in a silo of their own, but for the bigger ones… I’m not going to give exact numbers, but if you give every user a total of half an hour of unnecessary delays per day, that’s like 500 hours of wasted time per day per 1000 employees. Said employees were performing extremely overpriced services, so 500 hours of wasted time per day might be something like 100k income lost per day. Not an insignificant number even for billion dollar companies.
I’ve since left the company for greener pastures and I hear the new management sucks, but the old one for sure knew that they were going to lose their huge ass clients over performance issues and bugs.
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.
Ok, well really splitting hairs on what “working well” means but ok. Why do UX designers exist? I mean if you have a bad UI that takes a user 10 min to do something that can be done in 10 seconds in another solution, you lose. Time is money. Anyone who has ever been in magament knows it’s all about cost vs output. If a call center employee can handle 2x more cases with another solution due to a better UX, they will move to that.
You are saying efficiency doesn’t matter, which is just %100 false. A more efficient solution makes/saves more money. It saves time, which is also money and improves agility of the team. How can you say with a straight face that a business doesn’t care about efficiency of it’s workers…
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.
Ugh, wrong again. Time is money. People have limited bandwidth and output, you want to get at much output as you can for the salary spend while realizing each person has a finite output. You keep saying things like “time costs nothing” and “quality doesn’t matter” which are just completely wrong and if true would upend the industry.
Also I’ve been in software for just over 20, the last 4 of those as a CTO. Since you seem to keep bringing up your credentials for some reason.
In one thread someone questioned if I even work in tech. So I started mentioning my experience to back up my claims. My current CTO fully admits that we have to cut corners and deliver features to win customers. That why I work for him. He is honest about it. And he is not new at it either.
As for time is money… take a person working 40 hours a week, and replace thier tool with a cheaper lower quality tool, then tell them to make it work. They start working 44 hours a week. You saved money and got the same result. Awards for you. And a lot of people will do the extra work, because they care about the work. As a bonus, the people who won’t work extra leave. Now you have a self selecting group of people who will work longer for the same price. And those tend to be the people who won’t leave for various reasons. So now you can even not backfill some of the ones who left, and tell the ones who stayed to cover the slack. Wow, even more money saved. I’ve seen that happen at a company with billions in revenue and great profits. But the shareholders demand growth, so if they can’t sell more, they must cut expenses to grow profits.
That is true for outsourcing companies, but not true for product companies usually.
I think it’s equally true for product companies. Do you know how hard it is to get a company to prioritize bug fixing over feature work? Shy of a user revolt, or a friend of the CEO reporting an issue, bugs are almost always second priority or lower.
I’d say this strongly depends on the industry.
In an entertainment or ad sales product, I’d completely agree with you.
In a medical or financial product, the bug will take precedence.
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.
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.
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.
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.