Microsoft accused of a fundamentally flawed Windows 10 development process
3 min. read
Published on
Read our disclosure page to find out how can you help MSPoweruser sustain the editorial team Read more
By now we are all aware of the fiasco which has been the release of the Windows 10 October 2018 Update, but we probably already forgot that the April 2018 update was also delayed due to late-breaking bugs which caused blue screens on some PCs.
Ars Technica has taken a closer look at the development of Windows, and they believe Microsoft’s process of developing their operating system was flawed from the get-go, all the way back to even Windows 7.
They note that Microsoft has a process of actually writing code for new features of only a few weeks, and then spending the rest of the time (of several months) integrating the software and then ironing out bugs before release. This meant poor quality, unreliable software was introduced to the Windows 10 code base, and if issues are not found, delivered to the end user.
Coupled with an ineffective testing regime, in part due to Microsoft firing their SDTs in 2014 and placing more responsibility on developers to test their own code, and a Windows 10 Insider process by amateurs which was not comprehensive and which did not deliver professional bug reports, meant more than a fair share of bugs ended up being shipped.
Ars Technica also confirmed that Windows developers were allowed to integrate code without any testing at all, though hopefully, this was the exception.
They called for a change in Microsoft’s development process and asked that new software be well tested before integration using modern techniques such as automated testing, meaning that even Insider builds will have high quality, well-tested code with no “known issues”.
They note:
A new feature might be unstable during its development, but before that feature can be merged into the production code, it has to meet a very high quality bar. Rather than Microsoft’s approach of “merge the bugs now, we’ll fix them later,” the approach is to ensure that code is as bug-free as possible before it gets merged.
They conclude:
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.
Ars Technica holds Google’s Chrome team up as a company that is doing it right, and with ChromeOS becoming an increasingly viable option, Microsoft can certainly not afford to lose more trust from end users.
What do our readers think? Let us know below.
User forum
0 messages