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.

13 Comments

  1. WorknMan 2018-10-21 1:06 am EST
    • dpJudas 2018-10-21 2:01 am EST
      • A.Dev 2018-10-22 9:19 am EST
        • dpJudas 2018-10-22 10:29 am EST
          • A.Dev 2018-10-22 3:55 pm EST
      • avgalen 2018-10-22 9:49 am EST
        • ahferroin7 2018-10-22 11:43 am EST
          • avgalen 2018-10-23 9:09 am EST
  2. jmorgannz 2018-10-21 7:03 am EST
    • BlueofRainbow 2018-10-21 2:23 pm EST
      • ahferroin7 2018-10-22 11:37 am EST
  3. jmorgannz 2018-10-21 10:40 pm EST
    • ahferroin7 2018-10-22 11:38 am EST