Introduction
Most Neowin readers will be familiar with the concepts of beta software—an early release of software released for testing before the final, stable version. The terminology supposedly originated at IBM in the 1950s. An alpha (“A”) test was done internally to verify software before a public announcement, beta (“B”) tests were verifications done before releasing to manufacturing, and gamma (“C”) tests were verifications before releasing to the public. According to some sources, the terms were invented by IBM's Martin Belsky but were ultimately retired in the 1960s, not before gaining wider notice.
During the course of the 2010s, software companies transitioned from release cycles with longer testing periods to rapid releases. Google was the main instigator of this with its rapid Chrome updates, but firms like Microsoft and Mozilla soon took notice. Ever since Windows 10, Microsoft has moved to a Software-as-a-Service (SaaS) model, where it provides major upgrades for its existing operating systems.
Unfortunately, this software isn't always tested too well, as we saw with the Windows 11 Moment 5 update in 2024. After the update was sent out to Windows 11 users, several users took to the web to complain about installation issues, the blue screen of death, and black screen issues on startup. I wish I could say this was an isolated incident when it comes to rapid software releases, but it's not.
In this editorial, I will argue that Microsoft and other tech companies should slow down the development of their software in order to take proper care that updates are truly of a stable quality when pushed out to general users. More users than ever before have optional access to beta and developer channels if they want to try out experimental software. There's no reason major issues should get through to average users if more time is taken for quality assurance.
The decline of "stable" releases
Even going back to the days of Windows 95 through Windows 7, when major features were largely added at each new version, Microsoft has always issued security updates in a timely manner. Since 2003, it has been issuing security updates on Patch Tuesday (the second Tuesday of every month) to help admins protect the systems they're responsible for.
While Microsoft could take longer intervals between releasing the larger feature upgrades to ensure compatibility with existing devices, rather than blocking certain devices, the security updates, such as those released at Patch Tuesday, can't be delayed as they patch exploits.
In a recent example, people who installed Windows 11 version 24H2 via CD or USB with the October or November Patch Tuesday updates cannot update further. The company has fixed this now with the December Patch Tuesday, but it goes to show that extensive testing of the patches was not done. This led to problems for over a month for those wishing to install Windows 11 24H2 via CD or USB created with the official Media Creation Tool.
In the second half of 2024 alone, Patch Tuesday updates have also broken dual boot systems, the Start menu, and Wi-Fi. Obviously, with attacks on the rise, Microsoft needs to deploy patches fairly quickly, but it is a bit ironic that in the quest to avoid hacks, many systems get broken in the process.
Perhaps one solution for Microsoft to get a better handle on these issues would be to stop doing Patch Tuesday altogether. It has been a long time since they were introduced over 21 years ago, and Microsoft has gotten better at forcing updates on users. Perhaps it's better if individual security patches were pushed separately so that troublesome patches could be revoked without having to revoke other fixes too.
It's not only Windows that Microsoft has transformed into a service with feature updates. Ever since the Xbox 360, when Microsoft would drop massive UI changes, the potential for issues to open up in the Xbox lineup has increased too.
While it hasn't been an issue for most of this year, in the first four months, Microsoft was shipping Xbox updates with known issues present to general users. These issues pertained to intermittent audio issues and not connecting to the network on boot. Microsoft said both of these issues could be resolved by tedious system reboots—it did eventually fix the problem, though.
The system updates for Xbox are largely about pushing new features for its consoles. Given the fact that these new features aren't a matter of life or death, perhaps it'd be better for Microsoft to solve the known issues rather than dump them onto users who have not signed up to be beta testers.
Another company that now pushes software updates frequently is Mozilla. It changed to the rapid release cycle in response to Google's decision to do the same. Despite the fact that there is a Nightly and Beta channel, the stable Firefox channel, which most people use, also seems to get follow-up fixes after every release.
Firefox 133.0.3 (I'm not sure what happened to versions 133.0.1 and 133.0.2) is the most recent example of this. It was released just a few weeks after version 133 with fixes for missing scroll bars, invisible toolbar icons, and incorrect window positioning. Due to the rapid release of updates, things like these get overlooked and have to be fixed post-release.
The roots of the problem
The rapid release cycle, as mentioned earlier, arose during the 2010s for a combination of factors. Companies could adopt this release cycle to deliver features to users quicker and get a leg up against their rivals, at the expense of stability. Some of the enabling factors of this release model was the move away from installation media like CDs and the introduction of fast internet speeds that let browser and operating system updates get delivered relatively quickly.
Google with its Chrome browser is probably the most notable example of the adoption of rapid releases. It used these updates to subtly add new features and improvements every month without annoying users with big changes. As a result, it is the most popular browser in the world across desktop and mobile. While it uses its monopolist position to gain and maintain its marketshare, there is no doubt that its speed and simplicity are also major contributors to its popularity.
Most browser companies use Chromium as the basis of their own browsers now so they're onboard with the rapid releases too and Mozilla, along the way, realized it needed to switch to rapid releases so as to not lag behind. One notable difference with Chrome and Mozilla, however, is that Google barely ever touches Chrome's interface while Mozilla has gone through several interface refreshes. Frequent UI changes could be one factor for why Mozilla always seems to be pushing quite significant fixes for Firefox.
The Software-as-a-Service (SaaS) model adopted by tech companies for their products encourages their competitors to adopt it as well to keep up when it comes to features. These updates, as we often see with Microsoft's products, come with the option for users to send feedback to Microsoft, as if they were testing a beta product. Microsoft takes this feedback to further refine its software in yet another small, rapid update.
Web browsers can kind of get away with this model because they are free of cost and giving feedback to the maker could be considered a fair deal. However, when it comes to operating systems like Windows or the Xbox operating system, which you have paid for, it gets trickier to justify pushing buggy software just because you want to deliver features faster. As we can see from some of the examples above, disruptions to Windows users can be significant. If you had bought a car, you wouldn't expect the wheels to fall off, so why can Microsoft push software you've paid for that doesn't even boot properly in some cases.
The competitive case for Microsoft pushing these updates is also less clear. Its main competitor is Apple which only pushes OS updates once a year. Linux distributions also tend to only roll out major features with new major versions too, which makes it harder to see who Microsoft is trying to keep up with regular big updates. It could spend more time polishing the experience.
The impact on consumers
The rapid release of new software versions is what's officially called agile development. The idea is that you continually push updates that introduce new features quickly and solicit feedback to fix any issues via further updates. The main benefit of this model is that users get new changes quicker, keeping people more engaged in an increasingly distracting world.
The cost of agile development, however, is product stability and an inconsistent user experience. As we've seen with Patch Tuesday updates, even small updates can cause a big headache and ultimately erode users' trust in Windows. While agile development is certainly beneficial in a competitive market, this quick firing of updates shouldn't mean that beta-quality software is launched to users with a promise to make it stable over time.
Anyone who has run into issues with software and tried to troubleshoot the issue themselves knows that it can be incredibly frustrating and time consuming to resolve. That's just the impact to individual users dealing with problems on a single home computer.
For a system admin, resolving issues on a large number of machines can take even longer to resolve, impacting an organization's operations and costing it a lot of money from inactivity. As the world has become increasingly digitized, having stable systems that don't go haywire is even more important and it seems like at the time we need stability the most, companies are pushing instability in the pursuit of releasing undercooked features faster.
To quantify the damage done by IT outages to businesses, we can look at these figures shared by Atlassian from a no-longer accessible study by Gartner from 2014 which said that the average cost of downtime per minute for businesses was a staggering $5,600.
For any organization unlucky enough to be hit by a computer-breaking Patch Tuesday update, that could result in hours of downtime and a significant financial impact. A business impacted in that way could be more reluctant to continue using Microsoft software as a result. By spending less time on adding new features continually and focusing more on testing, companies can create less financial destruction and do less damage to their reputation.
With reduced trust from users due to previous bad update experiences, companies like Microsoft could see their users attempt to disable things like automatic updates to avoid bricking their system, until they've had a few days to see other users' reactions online to check if the updates are safe. This could leave users open to exploits on their unpatched systems.
Furthermore, if checks to ensure stability have been rushed, it could also mean that the code that has been written is also more exploitable. In the case of security patches, Microsoft could be there trying to help people while unknowingly introducing extra vulnerabilities into its software.
The agile method of software development, when properly implemented can improve the quality of code that's written, but when companies rush to push features, as is the case in practice, it can lead to corners being cut and buggy software being released.
Industry practices and consumer options
In its Windows as a Service (WaaS) overview page, Microsoft explains that it works with organizations throughout the development process to get things fixed before release where possible. It also does extensive internal testing with its employees who install new builds daily and a larger group of employees who install builds frequently, before the software even makes it out to testers among the public.
If poor software quality is consistent, it can give users negative impressions of the company who makes the software. We've seen this in the browser wars and people being fanboys or fangirls about the operating system they run on desktop and mobile. The instance of this that is probably out in popular culture the most is the Android vs iOS rivalry.
Google gives manufacturers considerable freedom when shipping Android which can lead to a very poor experience that may not even be Google's fault. Apple, on the other hand, has an iron grip over its ecosystem and many people appreciate how their devices just work. Of course, Apple has its share of issues too, as seen with the recent launch of iOS 18.
With software being relied on in most aspects of life, and people getting increasingly frustrated with beta-quality software being released as stable software, we could eventually see new development styles emerge. We could see better quality assurance emerge with more rigorous testing done on software before it goes out to the public, more emphasis placed on clean code principles that make it easier to fix bugs, and possibly a focus on smaller workloads which could allow for easier testing.
With regulators around the world getting concerned about the monopolist aspect of big tech, it could eventually be the case that they take notice of the reduced testing time for software as firms race to push out features. That could even lead to more regulations in the industry around testing software adequately.
I mentioned earlier that this paradigm of pushing features out to users as fast as possible and asking for feedback can be controversial, especially when the user has already paid for the software.
The main benefit of soliciting feedback from users in the real world is that they will be running the software on a diverse array of hardware. A niche bit of hardware that companies aren’t aware of may cause issues which can then be reported via feedback, this is all well and good.
Given the widespread occurrence of issues, though, something seems off. In the iOS 18 update I mentioned earlier, Apple controls all the devices which its OS runs on, yet people are reporting similar problems and it seems strange that Apple wouldn't have encountered these issues. Then there is the case of Windows 11 version 24H2 being blocked on two computers from the popular OEM, ASUS.
For general users who are not signed up to a developer channel, the assumption is that software is going to be stable when they buy it. The fact that it’s not and companies are soliciting feedback in a widespread manner is troubling. In many cases, those users who do provide feedback are not even compensated in any way by the companies.
The impact that average people can have in this area is pretty limited, I mean, have you ever looked for Google’s contact details? They’re basically non-existent. If you dislike this fast development pace that contributes to software bugginess then it’s probably best to leave negative, but constructive feedback, leave negative reviews, or switch to alternative software.
Another aspect of this discussion that I raised was to do with regulations. While buggy software has always been a thing and always will be a thing, with our growing dependence on technology, it’s not implausible that governments could impose stricter testing criteria. For general consumer technology, I believe this is too restrictive as you always have the choice to use something else if you don’t like it. While it could improve things for users, it could impact innovation and make things too bureaucratic.
Conclusion
Anyone that is fed up with buggy software upon release can take several actions. In the case of iOS 18 which launched with bugs, users on Reddit suggested holding off upgrading for a few weeks or months until bug patches have been released. In the case of Firefox, there is an Extended Support Release (ESR) which only gets big feature updates once a year with smaller security patches released alongside rapid releases of Firefox.
These are the two primary ways of not becoming an unwilling beta tester for software companies; hold off on the update for a few weeks or months, or find the long term support releases of software, if available.
To conclude, I am not sure if we will ever see a break away from this rapid development model where more incremental changes are made at shorter intervals, to the apparent detriment of software quality. These smaller updates have definitely taken the excitement out of software updates for me a little; I remember being excited when Firefox 4.0 came out with all the changes that were made. I don't get that excited much anymore with all the frequent updates bringing smaller changes.
If the rapidness does continue, then hopefully companies can do something about the perception users feel about being testers of beta-quality software. Perhaps a balance can be found where new features arrive quicker than they did at the start of the 2010s, but are also tested more thoroughly than they are right now.
13 Comments - Add comment