6 ms·

> Two QA per dev?? QA is a lot cheaper than dev. If your goal is to make quality software* on a fixed budget, you want to be QA-heavy. * Note: the OS definiti

by ethbr1 9mo ago

> Two QA per dev?? QA is a lot cheaper than dev. If your goal is to make quality software* on a fixed budget, you want to be QA-heavy. * Note: the OS definition of "quality software" drastically differs from your average app.

pousada 9mo ago
2 people doing QA per dev seems insane even if it’s a lot cheaper. M$ is hardly know for being obsessed with quality, they’d rather have 2 sales per dev (sales is even cheaper, basically pays for itself)
- mancerayder 9mo ago
  I've never known M$ to be lacking on the sales front, personally!
- CrossVR 9mo ago
  It's a lot easier to write code than to make sure it doesn't break something you didn't account for.
- razodactyl 9mo ago
  Microsoft's quality control used to be: release a buggy new OS then forge a solid next release. Going backwards in stability is out of character.
MiguelHudnandez 9mo ago
I feel that not only should QA staff outnumber developers, but QA staff should have access to development time to design and improve QA tooling. If you're doing an OS right, the quality is the product. I think MacOS prior to the launch of the iPhone would be the gold standard the kind of product design I'm talking about. At that time they were running circles around Windows XP/7 in terms of new features. They were actually selling the new OSes and folks were happy to pay for each roughly annual upgrade. Often the same hardware got faster with the newer OS. Lately Microsoft and Apple are racing to the bottom, it seems.
- razodactyl 9mo ago
  The irony here is that the market is willing to pay for quality. I don't have time to deal with phone issues-it should just work so I can get on with my day. Hearing that Apple were dedicating time to stop features and go after stability is exactly what I want to hear.
  - misiek08 9mo ago
    The saddest here is "were". iOS 26 is every day showing us that quality left Apple few years ago.
    - ethbr1 9mo ago
      I'm pretty sure that the recent shitshow (at least in iOS land) is the failure to have tentpole Apple Intelligence features, so scraping the bottom of the barrel and shipping things that were in no way finished (e.g. Liquid Glass UI/X).
dylan604 9mo ago
> QA is a lot cheaper than dev. QA is definitely one of those "you get what you pay for". A dev just bangs out code on what is assumed "happy path" which means the user uses it as the dev expects. QA has to some how think of all the inane ways that a user will actually try using the thing knowing that not all users are technically savvy at all. They are actively trying to break things not just feed in clean data to produce expected outputs. Let's face it, that's exactly what devs do when they "test". They are specifically trying to get unexpected outputs to see how things behave. At least, good QA teams do. I worked with a QA person who I actively told anyone that listened that the specific QA person deserved a higher salary than I did as the dev. They caught some crazy situations where product was much better after fixing.
- degamad 9mo ago
  > QA has to some how think of all the inane ways that a user will actually try using the thing knowing that not all users are technically savvy at all. The classical joke is: (this variant from Brenan Keller[0]) A QA engineer walks into a bar. - Orders a beer. - Orders 0 beers. - Orders 99999999999 beers. - Orders a lizard. - Orders -1 beers. - Orders a ueicbksjdhd. First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone. [0] https://xcancel.com/brenankeller/status/1068615953989087232?lang=en https://xcancel.com/brenankeller/status/1068615953989087232?...
- UK-Al05 9mo ago
  That's just a bad dev. Good devs don't think of just the happy path. My experience of QA as a quality focused dev has not been good.
  - tremon 9mo ago
    The purpose of QA is to identify the unhappy paths that the good devs missed, not to compensate for bad devs.
com2kid 9mo ago
Important to note MS used to have 2 types of QA: 1. SDETs (software design engineer in test) - same pay scale and hiring requirements as SDEs, they did mostly automated testing and wrote automated test harnesses. 2. STEs (software test engineer) - lower pay scale, manual testing, often vendors. MS used to have lots of STE ftes but they fired most of them in the early 2000s (before I joined in 2007). An ideal ratio of SDETs to SDEs was 1 to 1, but then SDET teams would have STE vendors doing grunt work.
- ThrowawayB7 9mo ago
  Having STEs as full time employees benefited MS greatly. They knew products from the end user and UI/UX perspective inside and out in ways even the SDETs didn't. UI/UX quality in MS products dipped noticeably after the STE role was eliminated.
  - ethbr1 9mo ago
    Imho, there are two key values that I've seen QA bring to software companies. 1. Deep user/product expertise. QA (and support) almost always knows more about how users (including expert users) actually use the product than dev. 2. Isolation of quality from dev leadership politics. It should be unsurprising that asking an org to measure and report the quality of its own work is fraught with peril. Even assuming good intentions, having the same person who has been developing and staring at a feature for months test it risks incomplete testing: devs have no way to forget all the insider things they know about a feature.
    - ryandrake 9mo ago
      The best places I've worked were places where QA reported up an entirely different leadership chain than engineering, and where they got their own VP with equal power as the engineering VP, and their own seat at the same decision-making table. When QA is subordinate to engineering, they become a mere rubber stamp. A good question to ask when joining a software company is "Does QA have the power to block releases over the objection of engineering?" I have found companies who can answer YES to this put out much better products.

by ethbr1 9mo ago

pousada 9mo ago

2 people doing QA per dev seems insane even if it’s a lot cheaper. M$ is hardly know for being obsessed with quality, they’d rather have 2 sales per dev (sales is even cheaper, basically pays for itself)

mancerayder 9mo ago
I've never known M$ to be lacking on the sales front, personally!
CrossVR 9mo ago
It's a lot easier to write code than to make sure it doesn't break something you didn't account for.
razodactyl 9mo ago
Microsoft's quality control used to be: release a buggy new OS then forge a solid next release. Going backwards in stability is out of character.

MiguelHudnandez 9mo ago

I feel that not only should QA staff outnumber developers, but QA staff should have access to development time to design and improve QA tooling. If you're doing an OS right, the quality is the product. I think MacOS prior to the launch of the iPhone would be the gold standard the kind of product design I'm talking about. At that time they were running circles around Windows XP/7 in terms of new features. They were actually selling the new OSes and folks were happy to pay for each roughly annual upgrade. Often the same hardware got faster with the newer OS. Lately Microsoft and Apple are racing to the bottom, it seems.

razodactyl 9mo ago
The irony here is that the market is willing to pay for quality. I don't have time to deal with phone issues-it should just work so I can get on with my day. Hearing that Apple were dedicating time to stop features and go after stability is exactly what I want to hear.
- misiek08 9mo ago
  The saddest here is "were". iOS 26 is every day showing us that quality left Apple few years ago.
  - ethbr1 9mo ago
    I'm pretty sure that the recent shitshow (at least in iOS land) is the failure to have tentpole Apple Intelligence features, so scraping the bottom of the barrel and shipping things that were in no way finished (e.g. Liquid Glass UI/X).

dylan604 9mo ago

> QA is a lot cheaper than dev. QA is definitely one of those "you get what you pay for". A dev just bangs out code on what is assumed "happy path" which means the user uses it as the dev expects. QA has to some how think of all the inane ways that a user will actually try using the thing knowing that not all users are technically savvy at all. They are actively trying to break things not just feed in clean data to produce expected outputs. Let's face it, that's exactly what devs do when they "test". They are specifically trying to get unexpected outputs to see how things behave. At least, good QA teams do. I worked with a QA person who I actively told anyone that listened that the specific QA person deserved a higher salary than I did as the dev. They caught some crazy situations where product was much better after fixing.

degamad 9mo ago
> QA has to some how think of all the inane ways that a user will actually try using the thing knowing that not all users are technically savvy at all. The classical joke is: (this variant from Brenan Keller[0]) A QA engineer walks into a bar. - Orders a beer. - Orders 0 beers. - Orders 99999999999 beers. - Orders a lizard. - Orders -1 beers. - Orders a ueicbksjdhd. First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone. [0] https://xcancel.com/brenankeller/status/1068615953989087232?lang=en https://xcancel.com/brenankeller/status/1068615953989087232?...
UK-Al05 9mo ago
That's just a bad dev. Good devs don't think of just the happy path. My experience of QA as a quality focused dev has not been good.
- tremon 9mo ago
  The purpose of QA is to identify the unhappy paths that the good devs missed, not to compensate for bad devs.

com2kid 9mo ago

Important to note MS used to have 2 types of QA: 1. SDETs (software design engineer in test) - same pay scale and hiring requirements as SDEs, they did mostly automated testing and wrote automated test harnesses. 2. STEs (software test engineer) - lower pay scale, manual testing, often vendors. MS used to have lots of STE ftes but they fired most of them in the early 2000s (before I joined in 2007). An ideal ratio of SDETs to SDEs was 1 to 1, but then SDET teams would have STE vendors doing grunt work.

ThrowawayB7 9mo ago
Having STEs as full time employees benefited MS greatly. They knew products from the end user and UI/UX perspective inside and out in ways even the SDETs didn't. UI/UX quality in MS products dipped noticeably after the STE role was eliminated.
- ethbr1 9mo ago
  Imho, there are two key values that I've seen QA bring to software companies. 1. Deep user/product expertise. QA (and support) almost always knows more about how users (including expert users) actually use the product than dev. 2. Isolation of quality from dev leadership politics. It should be unsurprising that asking an org to measure and report the quality of its own work is fraught with peril. Even assuming good intentions, having the same person who has been developing and staring at a feature for months test it risks incomplete testing: devs have no way to forget all the insider things they know about a feature.
  - ryandrake 9mo ago
    The best places I've worked were places where QA reported up an entirely different leadership chain than engineering, and where they got their own VP with equal power as the engineering VP, and their own seat at the same decision-making table. When QA is subordinate to engineering, they become a mere rubber stamp. A good question to ask when joining a software company is "Does QA have the power to block releases over the objection of engineering?" I have found companies who can answer YES to this put out much better products.