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.


  1. 2018-10-21 1:06 am
    • 2018-10-21 2:01 am
      • 2018-10-22 9:19 am
        • 2018-10-22 10:29 am
          • 2018-10-22 3:55 pm
      • 2018-10-22 9:49 am
        • 2018-10-22 11:43 am
          • 2018-10-23 9:09 am
  2. 2018-10-21 7:03 am
    • 2018-10-21 2:23 pm
      • 2018-10-22 11:37 am
  3. 2018-10-21 10:40 pm
    • 2018-10-22 11:38 am