Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software

Slashdot Asks: Should Tech Companies End the One-Year Software Update Cycle? 187

Posted by msmash from the who-is-it-for dept.
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?
This discussion has been archived. No new comments can be posted.

Slashdot Asks: Should Tech Companies End the One-Year Software Update Cycle? More

Slashdot Asks: Should Tech Companies End the One-Year Software Update Cycle?

Comments Filter:

  • I just want the names to make sense. (Score:5, Insightful)

    by XXongo ( 3986865 ) on Thursday December 21, 2017 @05:26PM (#55785745) Homepage
    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.

    • FF's frequent releases have ruined it (Score:2, Interesting)

      by Anonymous Coward

      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

      • I recall reading blog posts about app development and the author encouraging developers to release often so that users know your project is active. Personally I turned off auto update, and check through the list occasionally to see if an app I'm using has an update, and what features they have added. If all they say is "more bug fixes and features", or "we'll let you know of the features in the app", that app doesn't get updated, and may eventually be uninstalled. To me the frequent call for updates is annoying. Unless I'm actually experiencing a bug, or it's a security patch, I don't really care about the latest feature. If I did I would check if an update has been made available.

        I did have a bank force an update on me so it would be compatible with iPhone X, even though I'm using an iPhone 6s.

        I figure I've saved perhaps 100Gb of unneeded downloads for apps like YouTube, Facebook (while, this one is now uninstalled), and the various bundled iOS apps that are 500-1000 Mb.

        From my experience at Intel when they were trying to get into Android phones we start a cycle on a new version with everything broken and barely get everything working again just in time for Google to release yet another update which breaks something again. The point updates would take a couple weeks maybe to fix, but the major version updates were hell.

        My other experience from a user study which was for Intel's health and technology showed that it wasn't just Google that makes it shitty, and perhaps it wasn't Google at all, but every time we tested something and filed a bug the next day they would have marked all bugs as fixed and told us to test on the new version where we would inevitably find the same bug. Bug fixing makes them seem like they are making progress and looks like a good metric to management, where really they are just sweeping shit under the rug.

        • Release early / release often is not a new concept.

        • Re: (Score:2)

          by Kjella ( 173770 )

          and perhaps it wasn't Google at all, but every time we tested something and filed a bug the next day they would have marked all bugs as fixed and told us to test on the new version where we would inevitably find the same bug. Bug fixing makes them seem like they are making progress and looks like a good metric to management, where really they are just sweeping shit under the rug.

          Well bug fixing is a good metric, but refiled bugs should be a huge red-flag metric. If you're closing bugs that aren't actually fixed that's like improving support call times by hanging up on customers. That it can happen accidentally because the bug description or reproduction steps were unclear or incomplete is fine. That you made a botched fix that didn't completely address the issue or resolve it properly, fine. But if you're just saying we got a new version and are closing all bugs against the old one

        • I agree. The insane frequency of releases is what made me disable automatic updating for everything.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Apple and Ubuntu are particular egregious on this.

      "Requires OS X Tabby Cat". Um, I'm running 10.14... f--ked if I know; how does that relate to Tabby Cat?

      Third-party stuff for Ubuntu is just as bad. "Use download link x if you're running Lounging Lizard, link y if you're running Moping Marmot." What the f--k is that? I've got 16.04. Do I need link x or link y?

      Code names are cute and all, but come on, publishers, focus on something useful: cite version numbers.

      • Re:I just want the names to make sense. (Score:4, Informative)

        by Dragonslicer ( 991472 ) on Thursday December 21, 2017 @06:23PM (#55786103)

        Third-party stuff for Ubuntu is just as bad. "Use download link x if you're running Lounging Lizard, link y if you're running Moping Marmot." What the f--k is that? I've got 16.04. Do I need link x or link y?

        Code names are cute and all, but come on, publishers, focus on something useful: cite version numbers.

        That's more an issue with the third parties than with Ubuntu. For the most part, Ubuntu only uses version numbers on user-facing stuff, with version names used in things like the package repository names. They definitely aren't perfect about it, but they seem to be better than Apple.

        Connecting names to numbers can be annoying, but the names are always in alphabetical order, so at least you know which version is newer than the other (unless you're going back 10+ years).

        • Especially since there's no easy way to identify the name. There's no codename to be found on the Ubuntu page anywhere that would help link the version number to the name.

          I'm actually not sure how to find out the codename other than Google. Under Ubuntu's Settings > About all it shows is "Ubuntu 17.10"

          • If you're on the running system, the easiest way is with lsb_release -a in a terminal. You can also look in the repository lists in /etc/apt/.

        • but the names are always in alphabetical order, so at least you know which version is newer than the other

          Yes, but you lose other really important information that version numbers give you, such as "did this release include feature changes, or was it just bug fixes"?

          • As a general rule, yes, I agree completely. Operating systems are a slightly different case, though, especially with package-based systems like most Linux distributions. Individual packages have major/minor/patch version numbers, but the version number for Ubuntu as a whole system doesn't really contain that kind of information.

    • I agree -- this fad about giving releases names instead of version numbers is a serious pain in the ass.

    • windows 10 can use stuff like SP X or 10.X.X for the updates if just to give an quick way for people to see if they are up to date the build numbers are ok but not easy as say MAC OSX numbers or most linux distros have easy numbers like say centos 7.X. At least it's better then windows 8.

    • The names aren't supposed to make sense. They're supposed to be easy to report. It's so you can tell devs you're on "Namibian Tiger" and not feel embarrassed you're out of data, or fat finger 10.11.10 as 10.11.11

      You can usually get to the version number if you look.

      • I'm on Mac OS X 10.9.5.
        Do you know its retarded name?

        I don't ...

        After a 8 years Mac break my first new Mac was a 17" running Panther (10.4), bought 2004 ... that is the only thing I know about the retarded names of Mac OS X and now macOS.

        If you follow the "about this Mac" menu: it does not even tell you the name of the OS you are running.

        If you really need/want "retarded names" then use some that have an order, like planet names, or chemical elements or can be ordered alphabetically.

        Or the names of the mont

        • You're running the latest sub-version of "Mavericks". And the point isn't htat you have to look up the stupid name, it's that non-techie people can tell tech support/file bugs using a cute name and not scary numbers. If you were less of a techie, it's probably a lot easier for you to find the name, cause you would look elsewhere in the GUI.

          Them being in order would actually be worse... the lack of rhyme or reason means that they don't feel like disguised numbers. Which is important to not scare people.

          It

    • Even though "Alphabet" is the name of Google's parent it is still a good concept even when dealing with other companies. If you understood the alphabet you would know that N comes after M.

      • Even though "Alphabet" is the name of Google's parent it is still a good concept even when dealing with other companies. If you understood the alphabet you would know that N comes after M.

        Good to know. I was about to finally upgrade my Utopic Unicorn-- old but classic-- but now you have explained it to me, I understand that Aardvark would be a giant step back

  • Yes (Score:5, Interesting)

    by PhunkySchtuff ( 208108 ) <kai&automatica,com,au> on Thursday December 21, 2017 @05:26PM (#55785751) Homepage

    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?

    • Re:Yes (Score:4, Informative)

      by reanjr ( 588767 ) on Thursday December 21, 2017 @05:40PM (#55785825) Homepage

      No one really sells operating systems to consumers, via subscription or otherwise. MS sells OEM licenses. Apple sells computers with free OS upgrades. Linux vendors sell support. No one is paying fees to subscribe to OS releases.

    • You hit the nail on the head! It is funny that customers demand frequent improvements, love the subscription model, but then complain that there are annual updates. I think the issue is to make drastic changes with each of the major updates that upsets people.
      What do folks want? Have their improvements and new features, but don't install the necessary update for it? Or is it more that any new version is at times riddled with bugs that require frequent patching? If the latter, then we have the typical quali

    • Agree; it is all about subscription revenue. AutoDesk, Adobe, and Microsoft aren't about to turn that away, so neither will the rest of the pack.

      I would think it would start to make competitors more viable, but from where I sit it seems to further consolidate power.

  • One year cycles aren't for consumers benefit (Score:5, Insightful)

    by rsilvergun ( 571051 ) on Thursday December 21, 2017 @05:30PM (#55785769)
    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.
    • What the hell are you going on about? Starbucks has different blends, but they aren't "releases" and calling coffee "coffee flavored sugar water" is like calling Prime Rib "A1 smothered steak flavored cow muscle". It isn't served with sugar, and coffee is literally coffee flavored water.
      • and very few people buy their coffee black or with just a hint of milk or sugar. They just won't admit it when they're drinking their Unicorn or Christmas Tree Fraps. This isn't me being a mean spirited person. There's a body of marketing research that shows folks don't like to admit their personal tastes when asked. It's why marketing and market research is so hard. The way it was put to me (in a speech by Malcolm Gladwell although it wasn't his idea) is this:

        Ask anybody what their favorite coffee is a

  • Agile (Score:5, Insightful)

    by sunderland56 ( 621843 ) on Thursday December 21, 2017 @05:37PM (#55785805)

    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.

    • Indeed. But behind the whole "agile" gimmick, which is just there to make it look like it's remotely related to technical management, there's a devious business model that probably won't go away at least until the whole current economy collapses. It's all about securing continuous revenue. Like others have said, it goes hand-in-hand with subscription-based models. Once you get into this kind of business model, I don't think there is any easy way out. It's a trap.

    • I think upper management would prefer something more predictable than Agile. Agile is usually pushed hardest by new employees coming from places that were already part of the Agile cult.

  • Basically, they can't. (Score:5, Insightful)

    by XSportSeeker ( 4641865 ) on Thursday December 21, 2017 @05:45PM (#55785865)

    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.

    • Re:Basically, they can't. (Score:4, Insightful)

      by Hadlock ( 143607 ) on Thursday December 21, 2017 @06:02PM (#55785987) Homepage Journal

      This, pretty much. The product/sales/marketing departments are bred and educated on the yearly sales cycle; software development is ultimately dictated by them. The closest truce that I've seen has been the creation of LTS releases, which matches the annual or semi-annual cadence of the corporate sales/acquisition cycle with that of need for IT departments/software developers to ship and support stable software. Ubuntu's 2 years between LTS releases is rather long but it's extremely predictable and results in good stability with the interleaving releases being flexible enough to try out new features without screwing over seasoned IT professionals.
       
      For consumer products like the iPhone there will almost always be an annual incremental upgrade over last year; you don't want to sell the same product (iPhone, Laptop, Tablet*) two years in a row with no improvements at Christmas, you're looking at a sales disaster. You'd have to get rid of the Christmas sales season to effectively kill annual software updates.
       
      *The iPad seems to be the sole exception to this, the iPad Mini hasn't seen any significant upgrades since ~2013 and apple still sells the iPad Mini 2 despite being on version 4 or 5 now. Tablets with their larger batteries and internal volume pretty much maxed out on features within a couple of years of their introduction and hit full market saturation and last forever for whatever reason.

      • Ubuntu LTS still get SP like updates to it with an easy move update to the next LTS.
        Centos / redhat is an LTS of fedora.

      • Except that my two top-spec iPads and iPhone 4s were wonderfully responsive and fluid right until the last software update which, guess what, made them so slow as to be practically unusable.
        I'm sure that's just a coincidence...

      • This, pretty much. The product/sales/marketing departments are bred and educated on the yearly sales cycle; software development is ultimately dictated by them.

        This is true, but not in the direction you imply, I think. Left to themselves, most development and QA teams would release more often than once per year, not less. Or maybe never.

        Very long development cycles are bad, because they lead to developers trying to fit too much into each release, and they lead to developers racing the release deadlines. If your product is only released once per year and you miss the deadline, your feature isn't going to launch for another full year. That provides a strong motiva

    • Also iOS needs to come out on an annual basis in order to support the new features in the new iPhones and iPads that come out every year. It would be great if Apple could move away from the annual release cycle of the phones until they had the features working properly.

      • There is this demand from investors to not only make profit, but to make more profit than before. Changing the release cycle would send the stock plummeting as investors would believe they would be getting less return.

      • support the new features in the new iPhones and iPads that come out every year.

        Most of the time those aren't even phone features, but software features restricted to specific models. Remember when Siri first came out? What phone can't record audio with a microphone and send it to a remote server?

  • Just modularize the OS the same way others have already. Android is Linux based. Decouple the kernel from the UI API from the UI implementation. Same goes for other hardware layers of abstraction too. One of the biggest thing hurting Android to date is the lack of updates that need to be approved by both handset manufacturers and cell network carriers. We're stuck waiting months to years for updates, assuming we even get any at all. I'm currently on an Android device that can run every app I've downloaded f

  • They should spend the time fixing problems instead of making gratuitous interface changes. Useful major features only come along every few years anyway.
  • Major releases are for revenue enhancement. Bug fixes are there to keep the customer from getting totally pissed off. Quite frankly, it doesn't matter what package it is, fix the damn bugs. I need to get my work done, not build workarounds.

  • They use yearly releases to switch things around in the interface and change around options, as well as reset preferences.

    If there was consistency and refinement then that would be much more user friendly, not to mention carrying forward preferences and selected defaults as opposed to the big upheaval of installing a new version of Windows for example.

  • Would be thrilled if Apple actually had a yearly update cycle.

  • It's not like a 2 year release cycle would mean 1 year of developing the same features, followed by 1 year of beta testing.
    It would only mean 2 years of developing more new features followed by 6 months of patches instead of the 4 months of patches we get today.

    What is needed is more focus on testing, and less focus on new "features" that most people don't even want!

  • ...are these vendors to stay attached to their "income is the most important thing in the world" mindset, or do they take the more mature view that "customer satisfactions is vital to survival?" Clearly, most of all major industry is focused on the first, at the expense of long-term survival.

    There's a reason that some automobiles are preferred over others, but many customers will STILL buy the cheaper model...only to become disgusted with it's quality in due time. Same issue, same ultimate result: Merced

  • longer release cycles != less bugs (Score:3)

    by paulpach ( 798828 ) on Thursday December 21, 2017 @07:12PM (#55786361)

    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).

    • This is true, but the two aren't completely disconnected.

      Rapid release cycles and Agile development methods go hand in hand, and in my observations and experience, nothing has accelerated the decline in software quality as much as Agile development methods.

      We need to get rid of Agile, and when Agile is gone, rapid release will necessarily go as a side-effect.

      • If Agile means to you having less testing, you are doing it wrong.

        To the contrary, the best thing you can do in agile and DevOps in general is add automated testing and run all the tests on every single commit.

        • I never said Agile means you do less testing, although an awful lot of Agile practitioners seem to think that automated testing can replace or reduce the need for other sorts of testing, which isn't true at all.

        • Every blind-follower says exactly the same line: "you're doing agile wrong".

          Every company I've worked at, using agile, they ALL appear to be "doing it wrong" - especially with micro-management ("daily stand-ups"), along with a blame process ("sprint review"), and a continuous sprint-cycle to ensure your devs are constantly on a treadmill and never have time to think, evaluate, and innovate!

          What's worse is that it's some of the devs, who advocate for agile (i.e. blind followers), not knowing that it only ben

  • Yes (Score:3, Insightful)

    by JohnFen ( 1641097 ) on Thursday December 21, 2017 @07:19PM (#55786401)

    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.

    • What makes you think software quality is declining? I've been doing this for 30 years, and as far as I can see, everything has always been crap, with the exception of stuff that really, really had to work... and not always even then. Consider the Ariane 5 crash. And that was over 20 years ago.

      • You and I have been in the industry for roughly the same amount of time. I haven't done a study on this, so this is merely my own subjective perception. I don't know how to answer the "why do you think" question without simply restating my premise. I first noticed the overall decline in software quality about 15 years ago, but the pace of it has picked up over the past 5 or so. By "quality" I mean overall reliability, performance, and the number of nontrivial bugs.

        Software has never been perfect. I'm not cl

        • Without data, it's impossible to say. My perception is that it's actually better today than it was, particularly in light of the much greater complexity of today's software products. We do see more security bugs, but I think that's due to greater scrutiny, not more bugs.

  • It is insane. Our software is certified for the design of nuclear reactors and airplane structures and avionics. We have reporting requirements for our bugs to go to NTSB, FAA, DGCA, CRE a whole alphabet soup of agencies regulating nuclear power and airplanes from a dozen nations.

    The high, mighty and the wise people, otherwise known as the sales team, have pushed for and won three month release cycles. Planning meetings are immediately followed by progress review meetings with no time in the interim to ma

  • Otherwise you'll get a reputation for rush jobs and mistakes.

  • I hate the push to get something new out the door every single calendar year. On the corporate I.T. side, it's a huge time waster and hassle for I.T. staff, even if every one of those new releases was given away free. It's not just about the "big items" like new operating systems. It's all of the supplementary stuff that kills you with a thousand paper cuts. For example, we've had to start paying for the latest annual update to TeamViewer for our remote control software. Otherwise, if you decide you're "jus

    • Do you expect your annual salary every calendar year (in biweekly or monthly increments)? Or that the salary is paid "when the business is ready".

      There ARE new features, such as the ability for multiple users collaborating on a Word document to see the changes in real-time as someone types them. But how often did you CARE about that?

      Me not at all, but I know other people were really excited. And, importantly for MS, those are people who were moving to GoogleDocs because it had that feature.

  • 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.

    I'm fine with annual software updates if someone can explain to me the relationship between the need for a software update and the time it takes to orbit the Sun once. Otherwise just release the updates when they are ready to be released. If that is more often or less often than 1 year I don't care either way. Release it when it has been adequately tested and debugged and not a moment earlier except to consenting beta testers.

  • The companies I work for usually only upgrade Windows close to the point that software support is ending. This was the same for Win XP, and Windows 7. The fact that they are now doing 6 months for macOS and iOS.... seems insignificant in comparison.

    As an individual I move almost right away to a new version, but if I were a company I would not move until at least 2 patch cycles have completed -- and maybe longer (for macOS that is close to 3 months) -- and that is what I would consider fairly aggressive

Slashdot Top Deals

1 + 1 = 3, for large values of 1.

Close