alternate look by Ars at the same issue
Good article and a much needed wake up call to Redmond. Ars has an alternate take on this, which starts out with the same premise, that that Windows is broken, and suggests a complementary possible cause.
Basically, the author says that new features are developed in isolation, often without using automated testing. The active coding interval is surprisingly short, 8-10 weeks. Then, near the end everything is thrown into the pot together, integration testing - a lot of it manual - starts and bugs are slowly brought under control.
His concern is that this process, barely adequate at the best of time, managed to somewhat work under 3 year cycles. Under accelerated, cyclic releases, there just isn't enough time to corral all the bugs.
It seems kinda hard to believe that this would be the case, but I know of at least one ERP system, by a one of the usual billion $ suspects, where the development pipeline of 200+ engineers regularly came to a crashing halt whenever a bug made it to the build: there is only 1 test server. Must do wonders for software quality, when every bug, no matter how complex, requires immediate fixing to unblock everyone else. Bug found at 9pm Friday has to be fixed by 8am Monday. Every. Single. Time.
In a way, that is even more worrying that this article's premise. Sure, MS has enough money to throw more people at testing, and it should. And, sure, it should stop treating Insiders as a serious resource: witness their assent in the face of the Windows 8.0 GUI changes. Everyone else hated it, so they obviously weren't an appropriate way to gauge user acceptance or suitability.
But these remain fairly simple problems to solve, given the will and the resources.
But if MS's culture and tooling is incapable of using a mature and efficient process to flag bugs early in the development cycle, including issues arising from interactions between features, then changing that culture would be extremely challenging for any organization, let alone one with a product with as much technical debt as Windows and one with such a rich history of interdepartmental conflicts.
MS can't go back to 3 year cycles, but it also doesn't seem like it is at all capable of making do with 1 year cycles, at least not with its current way to approach development.