MS has had serious problems deploying its twice-a-year Windows 10 updates, most recently shipping an October Update that caused data loss and having to pull it.
This has led to a lot of criticism that the twice-a-year release cycle is responsible for all the problems, that it's too ambitious. As the headline implies, Peter Bright (not exactly a rabid anti-Microsoft guy) argues that the release cadence isn't the problem, MS's 1990s approach to software testing is. The approach appears to be "develop, then merge, then test" instead of "develop, test while developing, test some more, fix every blocking bug, then merge, then test some more."
The decoupling of development and bugfixing is also an issue: during the development and integration phases the reliability and stability of the software will take a giant nosedive. The features being integrated are fundamentally untested (because testing comes later), and have never been used with each other (because they were all developed separately in their own branches prior to the integration phase). The mess of software is then beaten into an acceptable shape through the testing, bug reporting, and bug fixing of the lengthy stabilization phase. In this process, the product's reliability should start improving once more.
[...]
Test the software before you ship it, not after
This tells us some fundamental things about how Windows is being developed. Either tests do not exist at all for this code (and I've been told that yes, it's permitted to integrate code without tests, though I would hope this isn't the norm), or test failures are being regarded as acceptable, non-blocking issues, and developers are being allowed to integrate code that they know doesn't work properly. From outside we can't tell exactly which situation is in play—it could even be a mix of both—but neither is good.
For older parts of Windows that may be a little more excusable—they were developed in an era before the value of automated testing was really recognized, and they may very well not have any real test infrastructure. But the OneDrive placeholders aren't an old part of Windows; they're leveraging a brand new set of capabilities. We might excuse old code being under-tested, but there's no good reason at all that new code shouldn't have a solid set of tests to verify basic functionality. And known defective code certainly shouldn't be merged until it's fixed, let alone shipped to testers.