12 ms·

Please stop putting salespeople in charge of highly technical product companies like Sonos. I'm so glad that Tom Conrad is an engineer by training. I hope he ca

by dguido 2y ago

Please stop putting salespeople in charge of highly technical product companies like Sonos. I'm so glad that Tom Conrad is an engineer by training. I hope he can turn this mess around. The key technical change that broke Sonos was abandoning their reliable UPnP (Universal Plug and Play) system for device discovery in favor of mDNS, while also shifting from direct device communication to a cloud-based API approach. This new architecture made all network traffic encrypted and routed through Sonos cloud servers (even for local operations), adding significant overhead and latency, especially for older Sonos devices with limited processing power. They also switched from native platform-specific UX frameworks to a JavaScript-based interface while moving music service interactions through their cloud instead of direct SMAPI calls, resulting in slower performance and reduced functionality. For a more extended discussion, see this excellent LinkedIn post from Andy Pennell, a principal engineer at Microsoft with a deep technical understanding of Sonos systems. He created one of the most successful third-party Sonos apps for Windows Phone and worked directly with Sonos on their official Windows Phone 8 app. https://www.linkedin.com/pulse/what-happened-sonos-app-technical-analysis-andy-pennell-wigwc/?trackingId=kSfNh0CXT2OTCTbZ%2FYpQrA%3D%3D https://www.linkedin.com/pulse/what-happened-sonos-app-techn...

stuff4ben 2y ago
It's not like the salesy-CEO was writing the code, there was still a bunch of engineers who said "hey this sounds like a great idea". Personally I want my CEOs to be on the sales side, make more money for the company. That being said you best have a good CTO/CIO that aren't sales-oriented.
- deleted 2y ago
  [deleted]
- rachofsunshine 2y ago
  One imagines a lot of the engineers going "yay!" are just people who want to have a job tomorrow.
- magicalhippo 2y ago
  Our company makes B2B for a rather technical niche. We got a sales-oriented CEO who knows when to listen to us developers. It has worked very well for our company. Being more sales-oriented he's found good business models and knows our customers well, and hence what our products are worth to our clients so we're not selling our products too cheap. This was the case before he took over from a more technical CEO. While a CEO with an engineer background can certainly do well too, I think it's probably easier to find a good sales-based CEO that simply knows when to listen to their technical team. At least in theory...
harrall 2y ago
Bruh an engineer probably suggested those changes. You think a salesperson is suggesting mDNS and frameworks?
- deleted 2y ago
  [deleted]
- Glawen 2y ago
  Yep, it is definitely an engineer behind this, wanting to show off. My job now is to deal with the aftermath of failed design choices at my company. It only took a couple of guys to impose their deluded design, because noone stood up to call their bullshit.
  - nar001 2y ago
    Can you expand on what design they chose and why it's bad? It could be an interesting read!
    - chiefalchemist 2y ago
      Scroll up. I've seen an overview mentioned about. The gist is: the architecture was good for the company and its revenue aspirations. The benefits to the customer a distant second. It wasn't so much what but why. The constraints of why led to risky anti-customer product decisions. Decisions the CEO had no choice but to own.
    - Glawen 2y ago
      We make embedded devices, the higher end are running linux. But, they developped the linux devices as it was a desktop computer, the biggest latency hogs we have are multiprocess architecture over dbus, and event based UI which fetches live data. The result is a slow and hanging UX, which gets slower after each update, and is irritating customers. The lower end devices we sell are bare metal, and they are liked by our customers due to their swiftness. They just have a different architecture that focuses on end result (monolith, and a cache of data to display).
- 2y ago
jedberg 2y ago
I don't think having a sales person in charge was the problem. The problem is the fundamental disconnect between what's good for users and what's good for the company. The company wants you to have to pay them money every month and control how you interact with the product, so that they can be a services company with recurring revenue. The consumer wants a device that they buy once and it just works.
- observationist 2y ago
  Engineers are in a better position to understand what the customer wants and needs. Salespeople are there to sell their product, and fundamentally don't need to understand what the customer wants, or needs. Give a good salesperson a handwavy outline of something to sell, and they will sell it. They don't need technical accuracy for success. Yes, this is bad for customers, and makes life harder, and results in ridiculous, counterproductive, infuriating situations for IT staff, engineers, and other people who have to deal with the technical realities of every day business. A salesperson can just mash psychological buttons in manager's brains, and they'll make the sale. The consumer, in enterprise level markets, is hardly ever the team or individual in charge of operating the technology. The consumer is the manager, or managerial team, looking to check boxes and shuffle numbers and spend $X on Y department, for which they get rewarded for a wide array of arbitrary outcomes, almost none of which have anything to do with the practical impact of the product in question on the people who end up most affected by the purchase. If an engineer with a solid understanding of the product being sold is in charge, he's in the best place to rein in the sales and marketing teams, and to direct development based on customer reality. This probably results in lower profits, overall, but a better product, and a better reputation in the long run.
  - redserk 2y ago
    Not sure if I agree with an engineer inherently being better here. The ideal case is having leadership who uses the product, or at least is willing to walk in the shoes of an end-user. Plenty of engineers do not do this either.
    - 2y ago
mananaysiempre 2y ago
> abandoning their reliable UPnP (Universal Plug and Play) system for device discovery in favor of mDNS I don’t know about that part. UPnP is exactly the HTTP-abusing XML-laden layer-spanning horrorshow you expect from 2000s Microsoft where it was mainly supported, mDNS is a fairly compact and neat set of independent extensions to preexisting Internet protocols born during Apple’s short period of flirting with open standards. In a greenfield project, you’d need to show me some really impressive tooling to make me choose UPnP, because five minutes with the specs are enough to tell implementing or debugging the thing is going to be a nightmare. (No experience with Sonos or their implementation of either.)
- stephen_g 2y ago
  I had the same reaction, all the other parts of the parent comment sound bad but switching to mDNS seems like the one that should have been an improvement or at least neutral...
  - packetlost 2y ago
    I'll second this. UPnP is wisely considered a bad idea and a security liability. mDNS usually just works and has been the foundation for several successful consumer platforms including Chromecast
    - throwway120385 2y ago
      As someone who has used mDNS professionally, it did indeed just work.
    - Spivak 2y ago
      Where are you getting reliable mDNS? I love the protocol on my own devices but good lord the Google Home ecosystem is terrible. Playing audio through multiple speakers at all, forget getting them in sync, is an exercise in frustration. And when I check by scanning mDNS it's always hung getting no responses from devices I know are there. The literal Chromecast itself seems to be exceptional device that just works.
deleted 2y ago
[deleted]
spamizbad 2y ago
Ditching a native framework for something JS-powered and running everything thru a cloud server sounds like technical decisions willfully made by engineering leaders.
- sgarland 2y ago
  Probably egged on by people telling them they had a much larger hiring pool if they went with JS (which is almost certainly true). Just once, I’d like to see a leader actively refuse these kinds of arguments when the process they have is objectively better. Never once have I ever experienced an Electron-ified version of an app and thought, “oh yeah, this is better.”
  - nox101 2y ago
    I have, it's called Visual Studio Code and I ditched my old native editor(s) for it. I'd even suggest that the fact that it's JS based has significantly changed the tech world because the editor itself will run in a browser so it's here https://godbolt.org/ https://godbolt.org/ , and here https://codesandbox.io https://codesandbox.io, and here https://www.postman.com/ https://www.postman.com/, and here https://aws.amazon.com/pm/cloud9/ https://aws.amazon.com/pm/cloud9/ and 100s or 1000s of other sites.
    - sgarland 2y ago
      VSC is the least bad Electron app I’ve ever used, but (heavily subjective) it pales in comparison to Neovim + Tmux. It’s not even close. Related: I was looking at WinRAR’s site last week after reminiscing about it with coworkers, and found that a. They haven’t really updated their UI since I last used it a decade+ ago b. The download is still 4 MB. THAT is why native is superior – if you know what you’re doing, you can get incredible performance with absurdly low filesizes.
      - 8note 2y ago
        why do i care about filezises though? storage is sized for HD video now
bigfatkitten 2y ago
This architecture sounds like a profound engineering failure, not a sales problem. The sort of failure that should get engineering leaders fired.
- x0x0 2y ago
  Hard to say. I'd bet there was a decent chance the eng team stridently warned the execs about what would happen and got overruled. https://arstechnica.com/gadgets/2024/09/it-was-the-wrong-decision-employees-discuss-sonos-rushed-app-debacle/ https://arstechnica.com/gadgets/2024/09/it-was-the-wrong-dec... In particular > Employees claimed that Sonos’ desire to get new customers and please investors was becoming more important than ensuring that old hardware would work properly with the new app. That sure sounds like this was a deliberate choice. That said, I suspect Sonos' market has mostly disappeared. A decade ago I paid $400+ to get streaming audio; now a lot of people are happy with Spotify Connect and $200 google speakers or a $50 refurb echo 4.
  - Nursie 2y ago
    If the software wasn't a shitshow, they compete in that bracket now via the Ikea Symfonisk range. They just really need to sort out the damn software.
  - bigfatkitten 2y ago
    It sounds like a secondary effect. They made a whole ton of really bad design decisions that ruined the product for current hardware, with breaking compatibility with existing kit being icing on the cake.
nl 2y ago
The new mDNS discovery mechanism works much better for me than the old one. I had two speakers that would constantly require reboots to be discovered with the old version but now they are 100% available.
insane_dreamer 2y ago
Those would have been CTO decisions or at least recommendations as to the technical merits of the change, not the fault of the CEO. Now if the CEO made the change for other reasons (usually financial, such as customer subscription lock-in) despite the technical downsides (which should have been presented by the CTO), then yes, in that case the blame would primarily fall to the CEO.
cabinguy 2y ago
Do you think a sales person or a technical person dreamt up those changes you believe broke sonos?
wouldbecouldbe 2y ago
This sounds more like a modern CTO felt the need to refactor the a big part of the codebase for the sake of it and if that wasn't foolish enough, they decided to not roll it out incrementally.
elevatedastalt 2y ago
These sound like extremely technical decisions that presumably engineering leads in the company came up with, signed-off on, and convinced leadership to go ahead with. I doubt a Salesperson has the technical expertise to initiate any of those changes.
- accrual 2y ago
  It could have been the other way around, though. Engineers could have been faced with calls asking for a higher degree of integration and dependence on cloud servers for profit reasons (carefully sold as better UX), then developed it because that's what they're paid to do.
Twirrim 2y ago
> especially for older Sonos devices with limited processing power. That reminds me: When S3 dropped support for MD5 ciphers, it ended up causing problems for a number of their customers who had remarkably old computers connecting to S3. The machines struggled to handle the newer / stronger ciphers they were now required to use. In one case it went from "just about keeping up" to "got no hope". That was a "fun" way to unexpectedly break folks.
- Terr_ 2y ago
  > The machines struggled to handle the newer / stronger ciphers Sort of like "test your stuff simulating a really shitty network connection", perhaps something else in that vein would be "test your stuff with excessively slow crypto and longer-keys."
urbandw311er 2y ago
Wow, thanks so much for the succinct and informative summary. I’m an owner of multiple SONOS speakers and am enraged by how these changes have effectively crippled my devices that I spent much hard-earned cash on. I am beginning to despair. I hope and pray they can just roll back half of them. I suspect it’s all related to centralisation and control and subscriptions to radio services and profit however so I won’t hold my breath. Most enshittifcation has profit at its root. :-(
jdswain 2y ago
I've implemented both UPnP discovery and mDNS, and mDNS was quite a bit easier to make reliable than UPnP. However, if they did have a reliable UPnP system, it would almost certainly destabilise the software for any transition like this. There's just so many different network issues to deal with, it's tough to debug when a user reports a problem and it's probably an issue with their router which is only sold in Germany. It is very frustrating class of bugs, when the app just doesn't find devices on the network.
jdmg94 2y ago
mDNS is superior to UPnP, they just made a compounding sum of bad choices that ended up in a bad architecture. I do hope companies start learning that you can't have suit doing running an engineering company
- Mindwipe 2y ago
  Google has engineers running an engineering company and that has turned every product for five years into a disaster.
  - surajrmal 2y ago
    This is a dramatic take. What's worse about Google photos today vs 5 years ago? Android seems a lot better off today than 5 years ago. I know there have been some bad things as well, but overall there have been more positives.
    - 392 2y ago
      I constantly get "memory" notifications from Google photos, to a degree that I suspect is a bug. It's more frequent than any other notification from my phone. It didn't used to be this way.
sholladay 2y ago
You blame the sales-oriented CEO for the problems but then point to a list of highly technical changes as the ultimate cause. A salesman knows nothing about these architecture decisions and would have trouble asking for them to be implemented even if they somehow knew it’s what they wanted to do. Could a more technical CEO have turned the ship around more quickly? Sure. But let’s be honest, the blame rests at the feet of the engineering team. Someone got excited about using some new tech and didn’t fully consider the ramifications. This happens all the time. And if you’re lucky, the code review saves you, or if not then QA saves you, or if not then the beta testers save you. If a problem remains after that, then it tends to become really hard to undo, from an organization perspective.
bmitc 2y ago
Engineering led companies can also be pretty miserable as well. Look at Google, for example.
raffraffraff 2y ago
Nice article by Andy. It's astonishing that they released that magnitude of change, and that they didn't provide a way to roll back once it showed itself to be a car crash. It should have been an opt-in beta, then opt-out, and maybe then after the bugs are squashed, incrementally rolled out. I understand why they'd to remove this big clatter of legacy protocols, simplify it, and encrypted everything. A tech-focused CEO would surely want that too, but perhaps might respect the amount of work and testing involved. What they forgot is that in a Sonos is a clatter of legacy protocols on top of speakers that are sonically "ok". Wasn't that their unique selling point? Why wouldn't a CEO with a sales background understand USP? As someone pointed out: they want to turn once-off purchases into monthly subscription. Maybe. They see this enormous userbase and brainstorm ways to squeeze recurring revenue out of it, but ironically they ruin the product and turn an army of advocates into enemies.
egorfine 2y ago
mDNS is far superior to UPnP. What casted a bad shadow over mDNS was the Apple's discoveryd vs mDNSResponder saga[1]. [1] https://www.macrumors.com/2015/05/26/apple-discoveryd-replaced-with-mdnsresponder/ https://www.macrumors.com/2015/05/26/apple-discoveryd-replac...
madeofpalk 2y ago
Tom Conrad was Chief Product Officer at Quibi. They're not out of the woods yet.
btreecat 2y ago
I'm not sure I understand the issue w/moving from UPnP to mDNS if everything was still locally accessible and managed. Kinda feels like those two issues are orthogonal.
xattt 2y ago
Is this reversed?
surajrmal 2y ago
I'm not sure any single one if those was necessarily problematic so much as the fact they did all of transitions at the same time and perhaps didn't do enough diligence in testing and slowly rolling out to ensure parity. For instance they could have rolled out mdns support with fallback to upnp and perhaps iterated untill they knew for a fact mdns was finding all the same devices as upnp with similar or better latency. However it seems that's not what they did. mDNS is used by all the major players in the iot space today and there is a reason for it. For instance I believe Chromecast uses mDNS for discovery. Routers have had a long time to work through any possible issues. New code will always suffer from bugs and I'm pretty sure that's been one of the problems they face more than anything else.

by dguido 2y ago

stuff4ben 2y ago

It's not like the salesy-CEO was writing the code, there was still a bunch of engineers who said "hey this sounds like a great idea". Personally I want my CEOs to be on the sales side, make more money for the company. That being said you best have a good CTO/CIO that aren't sales-oriented.

deleted 2y ago
[deleted]
rachofsunshine 2y ago
One imagines a lot of the engineers going "yay!" are just people who want to have a job tomorrow.
magicalhippo 2y ago
Our company makes B2B for a rather technical niche. We got a sales-oriented CEO who knows when to listen to us developers. It has worked very well for our company. Being more sales-oriented he's found good business models and knows our customers well, and hence what our products are worth to our clients so we're not selling our products too cheap. This was the case before he took over from a more technical CEO. While a CEO with an engineer background can certainly do well too, I think it's probably easier to find a good sales-based CEO that simply knows when to listen to their technical team. At least in theory...

harrall 2y ago

Bruh an engineer probably suggested those changes. You think a salesperson is suggesting mDNS and frameworks?

deleted 2y ago
[deleted]
Glawen 2y ago
Yep, it is definitely an engineer behind this, wanting to show off. My job now is to deal with the aftermath of failed design choices at my company. It only took a couple of guys to impose their deluded design, because noone stood up to call their bullshit.
- nar001 2y ago
  Can you expand on what design they chose and why it's bad? It could be an interesting read!
  - chiefalchemist 2y ago
    Scroll up. I've seen an overview mentioned about. The gist is: the architecture was good for the company and its revenue aspirations. The benefits to the customer a distant second. It wasn't so much what but why. The constraints of why led to risky anti-customer product decisions. Decisions the CEO had no choice but to own.
  - Glawen 2y ago
    We make embedded devices, the higher end are running linux. But, they developped the linux devices as it was a desktop computer, the biggest latency hogs we have are multiprocess architecture over dbus, and event based UI which fetches live data. The result is a slow and hanging UX, which gets slower after each update, and is irritating customers. The lower end devices we sell are bare metal, and they are liked by our customers due to their swiftness. They just have a different architecture that focuses on end result (monolith, and a cache of data to display).
2y ago

jedberg 2y ago

I don't think having a sales person in charge was the problem. The problem is the fundamental disconnect between what's good for users and what's good for the company. The company wants you to have to pay them money every month and control how you interact with the product, so that they can be a services company with recurring revenue. The consumer wants a device that they buy once and it just works.

observationist 2y ago
Engineers are in a better position to understand what the customer wants and needs. Salespeople are there to sell their product, and fundamentally don't need to understand what the customer wants, or needs. Give a good salesperson a handwavy outline of something to sell, and they will sell it. They don't need technical accuracy for success. Yes, this is bad for customers, and makes life harder, and results in ridiculous, counterproductive, infuriating situations for IT staff, engineers, and other people who have to deal with the technical realities of every day business. A salesperson can just mash psychological buttons in manager's brains, and they'll make the sale. The consumer, in enterprise level markets, is hardly ever the team or individual in charge of operating the technology. The consumer is the manager, or managerial team, looking to check boxes and shuffle numbers and spend $X on Y department, for which they get rewarded for a wide array of arbitrary outcomes, almost none of which have anything to do with the practical impact of the product in question on the people who end up most affected by the purchase. If an engineer with a solid understanding of the product being sold is in charge, he's in the best place to rein in the sales and marketing teams, and to direct development based on customer reality. This probably results in lower profits, overall, but a better product, and a better reputation in the long run.
- redserk 2y ago
  Not sure if I agree with an engineer inherently being better here. The ideal case is having leadership who uses the product, or at least is willing to walk in the shoes of an end-user. Plenty of engineers do not do this either.
  - 2y ago

mananaysiempre 2y ago

> abandoning their reliable UPnP (Universal Plug and Play) system for device discovery in favor of mDNS I don’t know about that part. UPnP is exactly the HTTP-abusing XML-laden layer-spanning horrorshow you expect from 2000s Microsoft where it was mainly supported, mDNS is a fairly compact and neat set of independent extensions to preexisting Internet protocols born during Apple’s short period of flirting with open standards. In a greenfield project, you’d need to show me some really impressive tooling to make me choose UPnP, because five minutes with the specs are enough to tell implementing or debugging the thing is going to be a nightmare. (No experience with Sonos or their implementation of either.)

stephen_g 2y ago
I had the same reaction, all the other parts of the parent comment sound bad but switching to mDNS seems like the one that should have been an improvement or at least neutral...
- packetlost 2y ago
  I'll second this. UPnP is wisely considered a bad idea and a security liability. mDNS usually just works and has been the foundation for several successful consumer platforms including Chromecast
  - throwway120385 2y ago
    As someone who has used mDNS professionally, it did indeed just work.
  - Spivak 2y ago
    Where are you getting reliable mDNS? I love the protocol on my own devices but good lord the Google Home ecosystem is terrible. Playing audio through multiple speakers at all, forget getting them in sync, is an exercise in frustration. And when I check by scanning mDNS it's always hung getting no responses from devices I know are there. The literal Chromecast itself seems to be exceptional device that just works.

deleted 2y ago

[deleted]

spamizbad 2y ago

Ditching a native framework for something JS-powered and running everything thru a cloud server sounds like technical decisions willfully made by engineering leaders.

sgarland 2y ago
Probably egged on by people telling them they had a much larger hiring pool if they went with JS (which is almost certainly true). Just once, I’d like to see a leader actively refuse these kinds of arguments when the process they have is objectively better. Never once have I ever experienced an Electron-ified version of an app and thought, “oh yeah, this is better.”
- nox101 2y ago
  I have, it's called Visual Studio Code and I ditched my old native editor(s) for it. I'd even suggest that the fact that it's JS based has significantly changed the tech world because the editor itself will run in a browser so it's here https://godbolt.org/ https://godbolt.org/ , and here https://codesandbox.io https://codesandbox.io, and here https://www.postman.com/ https://www.postman.com/, and here https://aws.amazon.com/pm/cloud9/ https://aws.amazon.com/pm/cloud9/ and 100s or 1000s of other sites.
  - sgarland 2y ago
    VSC is the least bad Electron app I’ve ever used, but (heavily subjective) it pales in comparison to Neovim + Tmux. It’s not even close. Related: I was looking at WinRAR’s site last week after reminiscing about it with coworkers, and found that a. They haven’t really updated their UI since I last used it a decade+ ago b. The download is still 4 MB. THAT is why native is superior – if you know what you’re doing, you can get incredible performance with absurdly low filesizes.
    - 8note 2y ago
      why do i care about filezises though? storage is sized for HD video now

bigfatkitten 2y ago

This architecture sounds like a profound engineering failure, not a sales problem. The sort of failure that should get engineering leaders fired.

x0x0 2y ago
Hard to say. I'd bet there was a decent chance the eng team stridently warned the execs about what would happen and got overruled. https://arstechnica.com/gadgets/2024/09/it-was-the-wrong-decision-employees-discuss-sonos-rushed-app-debacle/ https://arstechnica.com/gadgets/2024/09/it-was-the-wrong-dec... In particular > Employees claimed that Sonos’ desire to get new customers and please investors was becoming more important than ensuring that old hardware would work properly with the new app. That sure sounds like this was a deliberate choice. That said, I suspect Sonos' market has mostly disappeared. A decade ago I paid $400+ to get streaming audio; now a lot of people are happy with Spotify Connect and $200 google speakers or a $50 refurb echo 4.
- Nursie 2y ago
  If the software wasn't a shitshow, they compete in that bracket now via the Ikea Symfonisk range. They just really need to sort out the damn software.
- bigfatkitten 2y ago
  It sounds like a secondary effect. They made a whole ton of really bad design decisions that ruined the product for current hardware, with breaking compatibility with existing kit being icing on the cake.

nl 2y ago

The new mDNS discovery mechanism works much better for me than the old one. I had two speakers that would constantly require reboots to be discovered with the old version but now they are 100% available.

insane_dreamer 2y ago

Those would have been CTO decisions or at least recommendations as to the technical merits of the change, not the fault of the CEO. Now if the CEO made the change for other reasons (usually financial, such as customer subscription lock-in) despite the technical downsides (which should have been presented by the CTO), then yes, in that case the blame would primarily fall to the CEO.

cabinguy 2y ago

Do you think a sales person or a technical person dreamt up those changes you believe broke sonos?

wouldbecouldbe 2y ago

This sounds more like a modern CTO felt the need to refactor the a big part of the codebase for the sake of it and if that wasn't foolish enough, they decided to not roll it out incrementally.

elevatedastalt 2y ago

These sound like extremely technical decisions that presumably engineering leads in the company came up with, signed-off on, and convinced leadership to go ahead with. I doubt a Salesperson has the technical expertise to initiate any of those changes.

accrual 2y ago
It could have been the other way around, though. Engineers could have been faced with calls asking for a higher degree of integration and dependence on cloud servers for profit reasons (carefully sold as better UX), then developed it because that's what they're paid to do.

Twirrim 2y ago

> especially for older Sonos devices with limited processing power. That reminds me: When S3 dropped support for MD5 ciphers, it ended up causing problems for a number of their customers who had remarkably old computers connecting to S3. The machines struggled to handle the newer / stronger ciphers they were now required to use. In one case it went from "just about keeping up" to "got no hope". That was a "fun" way to unexpectedly break folks.

Terr_ 2y ago
> The machines struggled to handle the newer / stronger ciphers Sort of like "test your stuff simulating a really shitty network connection", perhaps something else in that vein would be "test your stuff with excessively slow crypto and longer-keys."

urbandw311er 2y ago

Wow, thanks so much for the succinct and informative summary. I’m an owner of multiple SONOS speakers and am enraged by how these changes have effectively crippled my devices that I spent much hard-earned cash on. I am beginning to despair. I hope and pray they can just roll back half of them. I suspect it’s all related to centralisation and control and subscriptions to radio services and profit however so I won’t hold my breath. Most enshittifcation has profit at its root. :-(

jdswain 2y ago

I've implemented both UPnP discovery and mDNS, and mDNS was quite a bit easier to make reliable than UPnP. However, if they did have a reliable UPnP system, it would almost certainly destabilise the software for any transition like this. There's just so many different network issues to deal with, it's tough to debug when a user reports a problem and it's probably an issue with their router which is only sold in Germany. It is very frustrating class of bugs, when the app just doesn't find devices on the network.

jdmg94 2y ago

mDNS is superior to UPnP, they just made a compounding sum of bad choices that ended up in a bad architecture. I do hope companies start learning that you can't have suit doing running an engineering company

Mindwipe 2y ago
Google has engineers running an engineering company and that has turned every product for five years into a disaster.
- surajrmal 2y ago
  This is a dramatic take. What's worse about Google photos today vs 5 years ago? Android seems a lot better off today than 5 years ago. I know there have been some bad things as well, but overall there have been more positives.
  - 392 2y ago
    I constantly get "memory" notifications from Google photos, to a degree that I suspect is a bug. It's more frequent than any other notification from my phone. It didn't used to be this way.

sholladay 2y ago

You blame the sales-oriented CEO for the problems but then point to a list of highly technical changes as the ultimate cause. A salesman knows nothing about these architecture decisions and would have trouble asking for them to be implemented even if they somehow knew it’s what they wanted to do. Could a more technical CEO have turned the ship around more quickly? Sure. But let’s be honest, the blame rests at the feet of the engineering team. Someone got excited about using some new tech and didn’t fully consider the ramifications. This happens all the time. And if you’re lucky, the code review saves you, or if not then QA saves you, or if not then the beta testers save you. If a problem remains after that, then it tends to become really hard to undo, from an organization perspective.

bmitc 2y ago

Engineering led companies can also be pretty miserable as well. Look at Google, for example.

raffraffraff 2y ago

Nice article by Andy. It's astonishing that they released that magnitude of change, and that they didn't provide a way to roll back once it showed itself to be a car crash. It should have been an opt-in beta, then opt-out, and maybe then after the bugs are squashed, incrementally rolled out. I understand why they'd to remove this big clatter of legacy protocols, simplify it, and encrypted everything. A tech-focused CEO would surely want that too, but perhaps might respect the amount of work and testing involved. What they forgot is that in a Sonos is a clatter of legacy protocols on top of speakers that are sonically "ok". Wasn't that their unique selling point? Why wouldn't a CEO with a sales background understand USP? As someone pointed out: they want to turn once-off purchases into monthly subscription. Maybe. They see this enormous userbase and brainstorm ways to squeeze recurring revenue out of it, but ironically they ruin the product and turn an army of advocates into enemies.

egorfine 2y ago

mDNS is far superior to UPnP. What casted a bad shadow over mDNS was the Apple's discoveryd vs mDNSResponder saga[1]. [1] https://www.macrumors.com/2015/05/26/apple-discoveryd-replaced-with-mdnsresponder/ https://www.macrumors.com/2015/05/26/apple-discoveryd-replac...

madeofpalk 2y ago

Tom Conrad was Chief Product Officer at Quibi. They're not out of the woods yet.

btreecat 2y ago

I'm not sure I understand the issue w/moving from UPnP to mDNS if everything was still locally accessible and managed. Kinda feels like those two issues are orthogonal.

xattt 2y ago

Is this reversed?

surajrmal 2y ago

I'm not sure any single one if those was necessarily problematic so much as the fact they did all of transitions at the same time and perhaps didn't do enough diligence in testing and slowly rolling out to ensure parity. For instance they could have rolled out mdns support with fallback to upnp and perhaps iterated untill they knew for a fact mdns was finding all the same devices as upnp with similar or better latency. However it seems that's not what they did. mDNS is used by all the major players in the iot space today and there is a reason for it. For instance I believe Chromecast uses mDNS for discovery. Routers have had a long time to work through any possible issues. New code will always suffer from bugs and I'm pretty sure that's been one of the problems they face more than anything else.