alt Hacker NewsThe arstechnica article was very good as a history of waterfall v sprint using MS as a case study. However the firing the QA department narrative is not supported:
Prior to these cuts, Testing/QA staff was in some parts of the company outnumbering developers by about two to one. Afterward, the ratio was closer to one to one. As a precursor to these layoffs and the shifting roles of development and testing, the OSG renamed its test team to “Quality.”
Two QA per dev?? That seems ginormous to me. What am I missing about the narrative about evil corp sending all of QA packing, that seems not supported here?
The second, Reuters article seems like it's saying something different than the QA firing narrative - it seems to talk about Nokia acquisition specifically and a smattering of layoffs.
Not supporting layoffs or eliminating QA, and I'm deeply annoyed at Windows 11. I just don't see these as supportive of the narrative here that QA is kaput.
Replies
I worked in the windows org around that time and the Dev/QA ratio there was closer to 1:1. QA did both manual testing and much of the automation, quality gates, and did regression testing against older versions of windows. Given the complexity of the product is is fairly easy for an inexpensive change to require an expensive test effort.
> Two QA per dev?? That seems ginormous to me. What am I missing about the narrative about evil corp sending all of QA packing, that seems not supported here?
I think you're underestimating the QA burden for large parts of the company. When I worked in payments at MS, the ratio of QA to dev after the cuts was probably on the order of dozens to one, if not a hundred or more once you threw in Xbox/Windows/etc accessibility QA from across the organization and all the other people like lawyers involved in handling over a hundred jurisdictions. I was little more than a frontend line cook and even I had three QA people reporting directly to me; two of them helping write tests so they ostensibly should have been automating themselves out of a job.
There is a lot of manual testing when you have a complex system like that where not everything can be properly stubbed out, emulated, or replaced with a test API key. They also have to be kept around to help with painful bursty periods (for us it was supporting PSD2, SCA, or 3DS2, forgot which). Payments is obviously an outlier because there is a lot of legal compliance, but the people I knew in Cloud/Windows also had lots of QA per dev.
I wouldn't be surprised if the degradation in feature parity of newer Windows software was a result of this loss of QA. Without the QA, the developers have to be less ambitious in what they implement in order to meet release schedules, and since they don't have experienced QA they can't modify the older codebases at all to extend them.
I had a QA engineer who gave me feedback on designs, great code reviews, and who wrote tests that I could also run.
It was a partnership. I miss it.
The Windows ecosystem is insanely complex. And they supported it, because of the focus on QA and testing the company adopted 20 years ago after the Blaster worm.
I have a few pretty awesome teams stuck managing windows. They find bugs all of the time. The process of fixing them now practically requires a detachment of druids and Stonehenge to track where in the windows/lunar/solar cycles we are and how to deal with the bullshit & roadblocks the support and product teams throw up. If you fall for their tricks, you’ll miss the feature window… no fix for 18 months.
It used to be much easier as a customer in ye olden times, and I never felt that the counterparty at Microsoft was miserable or getting punished for doing their jobs. We feel that now as customers. You didn’t establish relationships with engineers like with other vendors, but there was a different vibe.
The focus of the company moved in to Azure, service ops, etc.
In the chip design world, 2:1 for design verification to design is on the low end of normal.
Some organizations have gone as low as 1:1 but that is considered an emergency that must be fixed. It’s so important that designers will be intentionally underworked if there are not enough validation engineers on staff.
When you can’t fix bugs in the field, quality is important.
> 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.
> Two QA per dev?? That seems ginormous to me.
The only person I heard was writing perfect code was Donald Knuth. And even he had bugs in its code.
In writing life critical systems like the Space Shuttle's operating system, effectively 99.9% of all work is QA.
MS had the dominant operating system in the world, and keeping its userbase and its ~monopoly dividend would have been more profitable as a business than doing... everything it's done in the past twenty years. Selling software that all the people use all the time just has a lot less opportunity for growth than making new software, according to Investor Brain.