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

 



Forgot your password?
typodupeerror
×
IT Technology

How Sonos Botched an App and Infuriated Its Customers 47

Sonos launched a disastrous app update in May, prompting CEO Patrick Spence to commission an internal investigation led by chief counsel Eddie Lazarus. The software release, plagued with missing features and bugs, has sparked widespread customer outrage and led to a $200 million revenue shortfall. Sonos shares have plummeted 25% this year. Lazarus interviewed about two dozen employees and reviewed meeting recordings before presenting his findings to the board in late July. Bloomberg: What has happened to Sonos is at its heart a cautionary tale of company leadership ignoring the perils of "technical debt," the term used by software engineers to describe the compounding threat of outdated code and infrastructure on security, usability and stability.

For two decades, Sonos had allowed its tech debt to pile high. When it undertook in earnest its effort to revamp its app in mid-2022, the company knew it was sitting on infrastructure and code written in languages that were pretty much obsolete. The Sonos app had been adapted and spliced and tinkered with so often, the vast majority of work being performed for the new app was less about introducing new functionality than sorting out the existing mess.

The company could have tackled its tech debt sooner but appears to have lacked a crucial element: urgency. It finally came in the form of the Sonos Ace headphones, the first product in the Sonos range to be fully mobile rather than using home or office Wi-Fi. The app needed to be rebuilt, as did the cloud computing setup underpinning it.

Ace is a critical product for Sonos. Now that Sonos' pandemic sales boom has subsided, Wall Street has started to question where revenue growth will come from. Sonos Ace is a big part of the answer. Despite the company's lofty and well-earned reputation, Sonos' share of the $100 billion audio market is only around 2% because it has not gone toe-to-toe in the headphones category with Apple, Sennheiser, Bose and the rest.

How Sonos Botched an App and Infuriated Its Customers

Comments Filter:
  • The app needed to be rebuilt, as did the cloud computing setup underpinning it

    So, one less a cloud-enabled product plagues this world. Excellent news!

  • by Baron_Yam ( 643147 ) on Monday September 23, 2024 @11:40AM (#64809763)

    Declare bankruptcy and open a new account.

    Seriously - you build a parallel system and it's not done until it meets or exceeds the standard set by the existing system.

    Sonos gambled they could half ass it and get away with it, just another in the series of cheap moves that got them into trouble in the first place.

    • by ShanghaiBill ( 739463 ) on Monday September 23, 2024 @12:10PM (#64809853)

      Seriously - you build a parallel system and it's not done until it meets or exceeds the standard set by the existing system.

      Where do you get the people with the expertise to do that?

      The obvious source is to strip them from the legacy product, which means even fewer bugs are fixed.

      Then you have to deal with feature creep and second product syndrome [wikipedia.org].

      Why "starting over" is a bad idea [joelonsoftware.com].

      • Why "starting over" is a bad idea [joelonsoftware.com].

        That article was written in the year 2000 about Netscape. That is a different situation. In this particular case, Sonos released new app versions that broke/removed a lot of features from the previous version. The fundamental difference is that Sonos does not control the APIs of the ecosystem. Google and Apple control what APIs work on their phones. Sonos might be forced to rewrite if Google or Apple changes enough about the APIs.

      • Feature creep is not a problem on a properly managed project. You define your deliverables and barring discovery of a major oversight, anything else is for a follow-up project.

        If you don't run your projects that way, you're planning for disaster.

    • According to Sonos: "The redesigned Sonos app was built from the ground up to support both modern and future Sonos experiences"

      https://en.community.sonos.com... [sonos.com]

      Other sources / quotes do seem to contradict this though.

      Of course as you said, their biggest problem wasn't technical debt... it was releasing a crap product.

  • Penny-wise, pounded foolish.

  • by TigerPlish ( 174064 ) on Monday September 23, 2024 @11:43AM (#64809777)

    Not the only one. Last year, HiDive re-did all their apps, website, all of it.

    Giant fail. So bad that I bailed out. I have better use for $5 a month than supporting that clusterfuck.

    I guess design is dead, testing is dead, QA is dead, and let's just leave it all to the end user to sort out.

  • by simlox ( 6576120 ) on Monday September 23, 2024 @11:48AM (#64809787)
    Never rewrite your production software. Always renovate in smaller pieces. The software architects and developers will soon convince the managers of a total rewrite, but they are almost always wrong. Take the most buggy components first and get value for the investment much sooner.
    • by tele ( 246082 )

      I assume you never worked in a bigger company not managed by engineers? Tech debt reduction always takes lower priority than next quarter’s sales targets/functional features, you often need to wait for a big “event” to get the green light for tech renovation. Sure, you can hide some work behind functional changes, but this mainly helps with local/component-level tech debt, not with bigger issues.

      • by simlox ( 6576120 ) on Monday September 23, 2024 @12:17PM (#64809859)
        That is when big companies not managed by software developers fail: they build technical depth, and after some years the software developers, architects and middle management have the big solution: rewrite it all. Bad choice. Even with mountains of technicaldepth. I heard a Microsoft quote: Once the competition starts a complete rewrite, they knew that they were essential gone.
        • by _merlin ( 160982 )

          Companies do pull it off, though. Apple completely replaced their desktop OS stack with OSX, and they've replaced major parts of it multiple times since then. The Netscape browser was rewitten and became Mozilla. It was rough to begin with, but it got there. BIND9 was a complete rewrite, as that was the only way to fix the insecure architecture. Windows 95 and Windows NT were both rewrites.

          • "Windows 95 and Windows NT were both rewrites."

            NT was not a rewrite. It was a different product. It was sold concurrently with Windows for lesser machines, both windows 3.x and 95 (and 98 and ME) were sold this way. it took that long for computers to get fast enough to run Microsoft's cumbersome OS.

            By the same token, apple did not write NeXTStep. To turn it into OSX they only had to make the already portable OS run on their hardware, and fuck up the UI. Oh yeah, and ruin Display PostScript.

  • by bobm ( 53783 ) on Monday September 23, 2024 @11:52AM (#64809795)

    code written in languages that were pretty much obsolete..

    I'm scratching my head on that one. I wonder what languages that would be?

    Sounds like either an excuse or not hiring the right people, I'm guessing both.

    • Banks and Airlines can still find Cobol programmers. I'm guessing what Sonos used to originally write their App was more modern than Cobol.
      • Banks and Airlines can still find Cobol programmers.

        Cobol is a dead-simple language. You can learn it in a week.

        The banks and airlines aren't paying big bucks to the graybeards for their knowledge of Cobol, but rather their knowledge of the legacy codebase.

    • I'm scratching my head on that one. I wonder what languages that would be?

      I think Bloomberg being business centric did not get the tech terminology correct. After all the apps would not have worked if the languages were obsolete. More than likely the APIs and underlying code was obsolete. It appears that Sonos had not completely updated some code when Apple and Google released new versions of their app APIs over the years. More than likely Sonos kept patching any code to get it work in newer versions until it came a point when a complete rewrite was needed. But the scale of the

    • Probably python 2.

    • code written in languages that were pretty much obsolete..

      I'm scratching my head on that one. I wonder what languages that would be?

      "Pretty much obsolete" is a subjective judgment.

      I have seen many languages that I would not recommend for a new project: Ada, Fortran, Pascal, Perl, PL/1, Forth, Smalltalk, Snobol, Basic, Objective-C, Eiffel, Lisp, Simula.

  • by The Cat ( 19816 )

    There's a disconnect here, and everywhere else in the job market.

    How is it possible, given hiring managers' paranoid obsession with finding the absolute best candidate alive, and vindictively firing everyone else, that a high profile company can "botch" anything, much less an unremarkable mobile app?

    The people they hire must be peerless geniuses, given the exacting rituals undertaken to sweep legions of qualified candidates into the sea on the most scarce of justifications.

    And yet for some reason, in one bi

    • There's a disconnect here, and everywhere else in the job market.

      How is it possible, given hiring managers' paranoid obsession with finding the absolute best candidate alive, and vindictively firing everyone else, that a high profile company can "botch" anything, much less an unremarkable mobile app?

      Easy.

      • Don't listen to your engineers
      • Set unrealistic time lines
      • Provide insufficient resources
      • Profit! (or not, as the case may be...)
  • that freaked out the conspiracy types.

  • Management told them that they wanted feature x,y, z, and they wanted it by next week. But most management thinks programming is just click a few buttons on a gui, and you're good to go. What, you're not using AI chatbots to write the code?

    Are you trying to tell me it takes actual weeks or months of work, and you have to debug it, and test it? That's a waste of ROI... /snark

    • Without any technical knowledge, management could have simply tried to use the new version for a couple weeks before unleashing it on the world, and seen that it was not good to go.
      • Without any technical knowledge, management could have simply tried to use the new version for a couple weeks before unleashing it on the world, and seen that it was not good to go.

        Doesn't work. In that sort of QA, the people running it are testing what works and not looking for things that don't work.

    • No, what happened was that management said they wanted to be able to monetize their customers on an ongoing basis, which drove a number of bad decisions over time.

      They had some real challenges; their network stack was not well designed to optimize for crowed spectrum or large systems. They have fortunately moved beyond the "reboot dance" needed to optimize multiple wired connections, but not by much. Device setup was convoluted.

      Personally though I am still pissed that I cannot effectively have my home autom

      • by dfghjk ( 711126 )

        There is absolutely no evidence for any of this. Not that it will stop you.

        What do you know about their "network stack"? Their failure modes? Their goals to "monetize customers". Absolutely nothing, nor can you.

        "Device setup was convoluted."
        In what way? And how is it different now? Was? Sonos configuration isn't changing.

        "Personally though I am still pissed that I cannot effectively have my home automation select from any of the 20 or so common Spotify streams we use quickly and easily... if not auto

  • by PsychoSlashDot ( 207849 ) on Monday September 23, 2024 @12:28PM (#64809893)
    From the summary, "Wall Street has started to question where revenue growth will come from."

    Wall Street can get lost. Eternal profit growth isn't normal and it's not healthy. Know your product, know your market, know your strengths and play to those until you are in equilibrium. Be content with "enough money" and stop reaching for "all the money".

    Yes, it's important for a company to keep an eye open to emerging trends to make sure their existing market doesn't dwindle, but while you're in a position of strength, overreach is as dangerous as stagnation.
  • I don't doubt the app had obsolete underpinnings - though it was rebuilt just a few years ago for Sonos V2 devices. But that wasn't the issue: the app worked and didn't have (published) security issues.

    The impetus for rewriting the app didn't come from a "bite the bullet, it's time to fix this technical debt!" order. It came because their new products (one of which is the Ace headphones mentioned in the article, a new entry with mediocre reviews in an already very crowded field) needed an app rewrite to

    • by dfghjk ( 711126 )

      All correct. And the V2 transition was done well. What has happened since is a mystery, but it's not because of "decades" of "technical debt".

      The idea of headphones that "mimic" crappy soundbar surround is the least interesting product idea imaginable. I cannot imagine a less desirable feature from overpriced headphones sold by a MidFi company.

  • I have both the Sonos and Spotify apps on my Mac. There are occasionally times when I launch the Sonos app and it can no longer find its hardware. Like it dropped off the network.

    But the hilarious part is that the Spotify app can always find the Sonos hardware.

    Maybe Sonos ought to call Spotify and see how they did it.

  • Now that the money is at risk, demand an investigation!

    In layman's terms, this means the CEO is not really important at the company. Might as well replace them, a new one might actually care about the product and not the stock price. Ok I almost typed that with a straight face.
  • ...they couldn't build on open standards and for the local network, so the things would keep working whether the company went bankrupt or started removing features from products you've already bought or decided they wanted to brick your purchased product.

    These have all happened, except the bankruptcy, which is clearly a risk.

    Sonos the company is evil incarnate. Don't give them a cent.

  • The company could have tackled its tech debt sooner but appears to have lacked a crucial element: urgency. It finally came in the form of the Sonos Ace headphones, the first product in the Sonos range to be fully mobile rather than using home or office Wi-Fi. The app needed to be rebuilt, as did the cloud computing setup underpinning it.

    Um, shouldn't you have rebuilt the app alongside of developing the product? Shouldn't you have made sure the app was solid before committing to a release date?

    When things looked bad, you had a choice. You could have pushed back the release date, and had some egg on your face. Instead you chose to release crap, and now your company's in real trouble. Maybe next time you'll take short term pain for long term gain instead of the other way around.

  • Management is usually terrible at knowing if their engineers are competent. They have no idea if there is technical debt or just bad programming. Most programmers are crap. Most documentation is the wrong documentation even if it is up to date. I do contract work fixing embedded devices and luckily the code base is usually under 200,000 lines and a complete rewrite is possible. The hardest part, by a wide margin, is figuring out what the code is supposed to do. I've had clients that don't even documen
  • Garmin has a shit show on their hands with their Alpha app. This app is supposed to be the companion tool for their Alpha series of dog tracking GPS units. It didn't work all that well on iOS devices and on many Android devices didn't work at all. Then over the summer, they released a new version that took out a major feature thus making the app essentially useless. But Garmin also has the Explore app which does the same thing that the Alpha app did and that app actually works. All of this has you wond

  • by dfghjk ( 711126 ) on Monday September 23, 2024 @01:46PM (#64810181)

    This is just /. recycling garbage it knows nothing about.

    Sonos did not have "decades" of "technical debt" associated with its "app". The app hasn't even existed for "decades", Sonos has barely even been around that long.

    The sheer ignorance and stupidity constantly on display. on this topic really speaks to what /. has become. The people commenting don't even know what Sonos does or demonstrate that they've ever even used Sonos products. Worse yet, Sonos forced an app update out based on constant complaints about the app not getting updated from users, virtually the opposite of the ignorant diagnosis here.

    Sonos has long been to gold standard of avoiding "technical debt", not that /. readers would even understand that.

    • by DarkOx ( 621550 )

      True - iPhone was June 2k7; and it did not support third party native apps. I forget when they opened that up.

      In any case - We don't have any 'apps' that still work on any devices that run on any contemporary networks that can have 'decades' of technical debt associated with them. Literally the oldest apps realistically possibly are 17 years old or so.

      I guess you could potentially have ported something older... and brought some older crustier libraries along for the ride, but that is not so realistic in th

  • This is about a complete revamp that was released before it was ready for prime time, and didn't go through proper beta testing before widespread release.

    Tech debt, yes. But this is NEW tech debt taken on in the development of the new version.

    Following the home mortgage analogy, the old product is like that old house that has all kinds of things wrong with it, and still looks straight out of the 1970s. That's the 20-year tech debt. The homeowner decides that, rather than fixing the old house, he'll just dum

PL/I -- "the fatal disease" -- belongs more to the problem set than to the solution set. -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5

Working...