How Sonos Botched an App and Infuriated Its Customers 49
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.
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.
I felt sympathy for Sonos, until I read this (Score:2)
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!
Re: (Score:2)
Your mistake is believing that comment was accurate.
Re: I felt sympathy for Sonos, until I read this (Score:2)
Technical debt resolution (Score:5, Insightful)
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.
Re:Technical debt resolution (Score:4, Interesting)
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].
Re: (Score:3)
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.
Re: (Score:3)
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.
Re:Technical debt resolution (Score:5, Insightful)
Feature creep is not a problem on a properly managed project.
If Sonos was properly managed, it wouldn't be in its current predicament.
Re: (Score:2)
This was not "feature creep."
This was feature parity in a re-architected product, and that requirement for parity introducing development delays that management considered unacceptable.
Re: (Score:3)
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.
Re: (Score:2)
Seriously - you build a parallel system and it's not done until it meets or exceeds the standard set by the existing system.
Except that almost never works. There are plenty of companies that went under trying to do that, and it almost always damages the customer base even if successful.
Slow step-by-step refactorings are almost always the way to go.
As they mis-say (Score:2)
Penny-wise, pounded foolish.
Not the only one. (Score:3)
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.
Re: (Score:1)
It's seems charing 500 euros for headphones is not dead though!
Lack of experience: (Score:3)
Re: (Score:1)
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.
Re: Lack of experience: (Score:4, Insightful)
Re: (Score:2)
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.
Re: Lack of experience: (Score:2)
"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.
Re: (Score:2)
BIND9 was a complete rewrite
BIND4/8 were small projects, compared to modern products. However, BIND9 rewrite into BIND10 (called "Bundy") essentially failed. Instead, flexible storage backends, the raison d'être for BIND10, got added to BIND9.
code written in languages that were pretty much .. (Score:4, Insightful)
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.
Re: (Score:1)
Re: (Score:3)
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.
Re: (Score:1)
I take it, you've never worked on an enterprise COBOL project? Sure, you can read it. But do you understand what it's doing? What sort of business logic is being performed, and why? Do you understand the regulatory requirements that necessitated it being the way it is? On top of nested copybooks, nested CTRLIBs, obtuse use of ISAM and VSAM files. Java class inheritance hell it isn't, but they can have 40, 50, 60+ years of crufiness that defies explanation, reasoning, logic, and maintainability.
As for
Re: (Score:2)
If the program was written properly in the first place and the various additions to it were also properly written, you should be able to understand it. That's because COBOL was designed so that the bean counters could audit the code and make sure that the programmers didn't include sneaky code to steal from the company. If nothing else, any variables that are just a jumble of lett
Re: (Score:2)
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
Re: (Score:2)
Probably python 2.
Re: (Score: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.
Note (Score:1)
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
Re: (Score:1)
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.
Sounds too close to "Soros" (Score:1)
that freaked out the conspiracy types.
Easy to understand what happened (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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
"...where revenue growth will come from." (Score:3)
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.
CEO Patrick Spence to commission an internal .... (Score:1)
Did they hand him a mirror?
the "technical debt" was only part of it. (Score:2)
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
Re: (Score:2)
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.
Other company seems to do better (Score:2)
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.
CEO in it for the money, otherwise asleep at wheel (Score:2)
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.
Gee, it's just a real shame that... (Score:1)
...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.
Cart before horse (Score:2)
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 can't judge good software (Score:2)
Not isolated to Sonos (Score:2)
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
garbage retread of previous garbage article (Score:2, Interesting)
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 complain
Re: (Score:2)
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 NOT about 20 years of tech debt (Score:2)
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