How Sonos Botched an App and Infuriated Its Customers 65
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:2)
No, Sonos rewrote their app from scratch to produce a completely new version of it.
APIs don't change too much - Apple and Google don't change their APIs all that ofte
Re: (Score:3)
No, Sonos rewrote their app from scratch to produce a completely new version of it.
They wrote an app completely independent of Google or Apple APIs? What devices ran the apps again?
APIs don't change too much -
I beg to differ. APIs can change. In the case of Apple, they have even changed the language of apps by dropping Java and then Objective C.
Apple and Google don't change their APIs all that often because each API change will result in breaking apps that developers will then have to fix.
They do not wholesale change the APIs every single iteration. But they do change them and list them under deprecations. [apple.com]
Other that that, APIs are generally given plenty of time to be deprecated.
Again this story is about Sonos and their tech debt. In an ideal world, everything would have been done on time and Sonos would not have had these issues.
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:2)
That's like telling a new Yorker that rats aren't actually problem in a well cleaned city.
Re: (Score:2)
Where do you get the people with the expertise to do that?
Typically, you place an advertisement for a skilled engineer and then you interview them until you find one that is suitable. Was this a trick question? Did I miss something?
They are not working on rockets or brains. Their stuff is not THAT difficult to understand and to rewrite, especially since they already have all the data needed to produce what currently exists. It is really not difficult, it just costs money (which is where all of the difficulty lies).
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:3)
"The redesigned Sonos app was built from the ground up to support both modern and future Sonos experiences"
Let me translate that for you: The redesigned apps are designed to make servers on the internet become Integral to the product's core functionality so they can collect as much data as possible and track you and everything you do.
The new version of the App even REQUIRES that you register and login to an account on Sonos servers with a Username and Password and Grant permission to geolocation data
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:4, Insightful)
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:4, Insightful)
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:5, 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:4, Informative)
"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:3)
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.
Re: (Score:2)
Windows 95 and Windows NT were both rewrites.
Windows NT was a rewrite, and it took 10 years from 1992 (the first NT) to 2002 (Windows XP) to move users to that OS. So if you can survive for 10 years supporting two parallel products, then rewriting might be a good idea.
Windows 95 was most definitely NOT a rewrite, it quite famously reused the 16-bit "kernel" from Win 3.11. Moreover, Win95 itself was based on technologies from the earlier Win32s add-on that allowed users to run 32-bit apps in Windows 3.11.
Re: (Score:2)
Once the competition starts a complete rewrite, they knew that they were essential gone.
That is only true in situations where you have eliminated all the skilled employees because their salaries were too high. You get what you pay for... even if you can coast for a while.
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)
Why wouldn't they work? If you have the runtime and and the binaries, it'll work if it ever did, no matter the age. If you still have the compiler, as long as you don't update the platform, you can produce new binaries. Clearly the old platform is still available since they were still selling hardware with the old code on ity.
The issue would be getting in new developers with any level of proficiency with the language or even with a willingness to learn something that won't likely ever be useful again.
What r
Re: (Score:2)
Why wouldn't they work? If you have the runtime and and the binaries, it'll work if it ever did, no matter the age. If you still have the compiler, as long as you don't update the platform, you can produce new binaries. Clearly the old platform is still available since they were still selling hardware with the old code on ity.
Apple like Google allows developer to compile against a specific API version for a while; however, eventually that version will be obsolete. While there are more options for Android developers to side-load, developers cannot use iOS 1.0 nor Android 1.0 forever officially. Eventually they will have move to newer versions.
APIs get deprecated all the time in newer versions. There are a number of ways to correct for this. The easiest way is to patch the code just enough to where it works. Over time, that patch
Re: (Score:2)
By new developers, I'm not suggesting hiring a bunch to somehow overcome debt. I'm talking about replacement level hiring to maintain the size of a dev team. Part of deep technical debt happens when the languages and tools you use are so old that incoming replacement devs would have to learn them as a new skill. If that skill is a dead end, good luck enticing new employees.
By platform, I mean the platform their firmware runs on, which is completely within their control. Their claim was that they HAD to upda
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.
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:1)
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
"...where revenue growth will come from." (Score:4, Interesting)
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.
Re: "...where revenue growth will come from." (Score:2)
...then use the extra money you've made to start a new product, with an open revenue potential.
Re: (Score:2)
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.
Guess who profits off of all the pieces of the broken company? Not investors, but Wall Street themselves. Then, there is space to Venture Capital another fraudulent scheme to transfer a few more billions into their wallets. There are very few 'honest' businesses left in America, and the scavengers are biting at their heels constantly. A miserable excuse for an economy that at one time, dominated the entire planet from production rather than slimy business deals.
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:4, Insightful)
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:4, Informative)
When I'm done a contract, I leave everything documented with what the code does. I leave a readme_first.txt that says where all the documentation is, what is documented, the full build and testing. I will also list, and in great detail if security is involved, the why. And in 4 out of 5 cases no one will ever read the documentation and the 5th it will be me when they hire me back. There is no money in doing it right. No one will appreciate it. There certainly is no job security. If you do it right you are only doing it for your future self.
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:3)
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 dump it and build a new one. The old (tech) debt gets paid off when he sells the house, he no longer has to worry about that. But he decides to move into the newly built house before the drywall and cabinets are installed. *That's* the new release, the new tech debt, that Sonos decided to foist on their customers, hoping it would be "good enough."
Minimum Viable Product fallacy (Score:2)
Looks like once again a company fell victim to the pitfalls of the minimum viable product. The management set an unrealistic deadline, told engineers to squeeze in core features only, and release a product that is "good enough". Good enough for non-technical, short-sighted, greedy bastards at the top; detached from reality and unable to forsee the very obvious outcome of their actions. Obviously, not good enough for users.