Comment by sgarland
4 days ago
Correction: devs have made the mistake of turning everything into remote calls, without having any understanding as to the performance implications of doing so.
Sonos’ app is a perfect example of this. The old app controlled everything locally, since the speakers set up their own wireless mesh network. This worked fantastically well. Someone at Sonos got the bright idea to completely rewrite the app such that it wasn’t even backwards-compatible with older hardware, and everything is now a remote calls. Changing volume? Phone —> Router —> WAN —> Cloud —> Router —> Speakers. Just… WHY. This failed so spectacularly that the CEO responsible stepped down / was forced out, and the new one claims that fixing the app is his top priority. We’ll see.
Presumably they wanted the telemetry. It's not clear that this was a dev-initiated switch.
Perhaps we can blame the 'statistical monetization' policies of adtech and then AI for all this -- i'm not entirely sold on developers.
What, after all, is the difference between an `/etc/hosts` set of loop'd records vs. an ISP's dns -- as far as the software goes?
> Presumably they wanted the telemetry
Why not log them to a file and cron a script to upload the data? Even if the feature request is nonsensical, you can architect a solution that respect the platform's constraints. It's kinda like when people drag in React and Next.js just to have a static website.
someone out there now has a cool resume line item about doing real time cloud microservices on the edge
You’re right, and I shouldn’t necessarily blame devs for the idea, though I do blame their CTO for not standing up to it if nothing else.
Though it’s also unclear to me in this particular case why they couldn’t collect commands being issued, and then batch-send them hourly, daily, etc. instead of having each one route through the cloud.
We (probably) can guess the why - tracking and data opportunities which companies can eventually sell or utilize for profit is some way.