It isn't how often MS updates Windows; it's how it develops it

Developing a Chrome-like testing infrastructure for something as complicated and sprawling as Windows would be a huge undertaking. While some parts of Windows can likely be extensively tested as isolated, standalone components, many parts can only be usefully tested when treated as integrated parts of a complete system. Some of them, such as the OneDrive file syncing feature, even depend on external network services to operate. It's not a trivial exercise at all.

Adopting the principle that the Windows code should always be shipping quality - not "after a few months of fixing" but "right now, at any moment" - would be an enormous change. But it's a necessary one. Microsoft needs to be in a position where each new update is production quality from day one; a world where updating to the latest and greatest release is a no-brainer, a choice that can be confidently taken. Feature updates should be non-events, barely noticed by users. Cutting back to one release a year, or one release every three years, doesn't do that, and it never did. It's the process itself that needs to change: not the timescale.

The latest Windows feature update had to be pulled due to a serious data deletion bug, so it makes sense to take a good look at the development process of Windows, and what can be changed to prevent such problems from appearing again.