Slashdot Mirror
Slashdot Asks: Should Tech Companies End the One-Year Software Update Cycle?
Software giants Google, Microsoft, Apple and others release a major software update to their desktop and mobile operating system (and OS for other platforms they have) each year. This model seemed viable -- to a consumer -- until a few years ago -- the days when shiny new features were exciting -- but of late the number of bugs that companies are failing to patch before shipping these operating systems has seemingly gone off the roof. For instance, Apple has released more than 10 software updates since seeding out iOS 11 in September this year (up from seven last year). Similar is the case with macOS.
The situation has gotten so dire that IT admins in many corporate environments are waiting for as long as six months before they are certain that it is fine to get the staff to move to the "newer" major software update. For companies like Apple, new software update also means a business opportunity. Several of the new features that they ship with the new update doesn't work with older iPhone and iPad models. And as we learned this week, new major software updates could hinder the performance of old gadgets. With these things in mind, should industry at large consider prolonging the duration between two major software updates? Or should they stick with a one-year software cycle model?
The situation has gotten so dire that IT admins in many corporate environments are waiting for as long as six months before they are certain that it is fine to get the staff to move to the "newer" major software update. For companies like Apple, new software update also means a business opportunity. Several of the new features that they ship with the new update doesn't work with older iPhone and iPad models. And as we learned this week, new major software updates could hinder the performance of old gadgets. With these things in mind, should industry at large consider prolonging the duration between two major software updates? Or should they stick with a one-year software cycle model?
I just want the names to make sense. I'm not sure if my OS-X "Namibian Tiger" is supposed to be updated to "Mount Rushmore" or vice versa, and I'm not sure if either one is compatible with Hasta-la-vista. And I've completely given up trying to understand whether my red hat is a fedora or not, or whether peppermint comes before chocolate chip, or after.
Yes /thread
Now that software companies are hooked on the recurring revenue of subscription-based pricing and their end users have seemingly accepted it with little fanfare, I don't see the subscription model going away any time soon.
The trap is that software companies now want to be seen as giving continual improvements (and therefore value) to their customers, so they push out annual updates (as most subscriptions are an annual subscription) just so that people are using WhateverApp 2018 instead of WhateverApp 2017. It's got a bigger number in it's name, it must be more better. Or, why am I paying a subscription for WhateverApp 2015 and it's nearly 2018? What has the vendor been doing for the last two years to deserve my money?
Specialist Mac support for creative pros, Melbourne
they're for habituation. They want you in the habit of buying on a schedule so it feels 'off' if you miss a beat. Starbucks uses this to keep folks drinking their coffee flavored sugar water. Let it go too long and consumers forget about you. That's why we got Windows ME & Vista.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Internally all these companies preach "Agile" and "continuous software delivery". Guess that's just all to pacify upper management, since it isn't really working.
Worse than even annual releases are the much more frequent releases of web browsers, mainly FF. Early on, FF used to have relatively infrequent major releases, but when they did come out they were good news. They brought lots of great improvements, and new FF releases were something to look forward to. Then around FF 4 they started moving toward more frequent releases. I think it has been awful, cumulating in what has been the worst release for me yet, the recent FF 57 that broke nearly all of my extensions and that ruined the UI. All that these frequent releases do is let the FF developers shovel shitty changes on to us users every few weeks. Rapid releases don't encourage doing a good job. They just encourage lots of unwanted change for no good reason that's then forced on users who never asked for these changes and who don't want them. The ESR releases don't even help because they're just specific versions of the rapid releases. They're afflicted with the same flawed development model as the frequent releases.
The answer is yes, but tech companies won't do it, because these things have nothing to do with consumer needs, but are instead strictly tied to stuff like marketing, and advertising. And it has huge sprawling effects that are hard to predict and figure out.
For companies like Google, Apple and Microsoft, software cycles don't live in a vacuum. They are tied to advertisement campaigns, keynotes, presentations, relationships with press, developers, business contracts, and a whole ton of other stuff people might not be aware of.
It takes far more than what the article is complaining about to tip the scale.
Ubuntu which is the most like Debian instead has a 6 months release cycle and they constantly have shit-tons of problems with every new release, same with Windows which also moved to a 6 months cycle now.
If you don't like how quickly things change in the normal Ubuntu releases, stick to the Long-Term Support releases, which are, like Debian, every 2 years.
You're not buying into that "Continuous Deployment, ship a new build to production every night!" BS, are you? Automated code testing is still no match for real end-user testing, and you're going to eventually release shit code to production if you rely on it.
The assumption here is that with longer release cycles there will be less bugs.
This just does not follow at all. You may think "but they would have more time to fix bugs", sure, but they will also have more time to add new bugs. Every new feature will have a corresponding number of bugs, having larger releases means having more features per release. Maybe you think "keep the amount of features the same just do more testing" sure, but they can do that with smaller releases as well.
If a company releases every 2 years, that means that a bug will be sitting there unpatched for 2 whole years. The new release may fix all those bugs, but it will also introduce a whole set of new bugs that will stay there for 2 more years. If the same company releases every month, then the worst bugs will be squashed within a month or two. The bugs that survive longer are the low priority ones. By having frequent releases and prioritizing the defects properly, the same company can keep a higher overall quality.
A customer may decide to upgrade only every 2 years, in which case, the customer is not affected by how many releases are made, so they are not worst off.
If you do software development right, the real question is not "is the software ready to be shipped?". Your software should ideally always be ready to be shipped. The real question is "which features are ready to be shipped", you would simply merge the features that are ready and tested. Anything that is half baked will be left for future releases. This model decouples release cycle and quality. The quality question then becomes an issue of how much testing each individual feature has (automated testing FTW).
Although there are many things that are contributing to the ongoing decline in software quality, I think "rapid release" and similar Agile-inspired release cycles have done more to speed up the problem than any other single factor.
Ditch it.
How's life in the hypocrite lane?