Sonos execs considering bringing back the old app
General rule for all companies: When something succeeds, management wins. When something fails, the working class loses.Funny how layoffs never seem to affect the management that made the monumental fuckups to begin with.
100% guaran-fucking-teed that many who were laid off knew the new app was shit, said so, and were ignored.
Multiple somebodies at the top of the company signed off on pushing these changes. They won't be fired, of course, but they signed off on it.This most recent layoff wave comes as Sonos is expected to spend tens of millions of dollars to address the fallout from its updated app. Released in May, the update removed various functions, including the ability to use sleep timers and access local music libraries and accessibility features.
I bet almost every engineer knew this "new app architecture" was garbage too.Funny how layoffs never seem to affect the management that made the monumental fuckups to begin with.
100% guaran-fucking-teed that many who were laid off knew the new app was shit, said so, and were ignored.
Discounts are almost always a trap. It's basically an attempt to entrench a customer even more, making the sunk cost fallacy hit harder the next time Sonos screws them over.win back customer and partner trust with things like discounts.
Ah the classic rewrite trap that any seasoned engineer will tell you to stay away from.
You should never rewrite the existing app. You replace parts of it at a time with testing to ensure you're not mucking things up
This reminds me of where I work as a "manager" but I'm really a web dev.Does that include every manager and executive that signed off on it?
I'm sure the blame and penalty hasn't been completely passed onto the working class employees.
There’s got to be balance here, lest you end up with Delta Airlines technology stack.
Sounds like they're not using the new app for much, because it's incapable, but FTA people used the old app forAs someone with Sonos throughout their entire house (9 speakers and a sub). I wasn't even aware there was a problem and aside from setting up my system or adding speakers...I've never opened up the Sonos app.
I got a new phone 9 months ago and I realized I never even installed the sonos app. What are people using this for?
the ability to use sleep timers and access local music libraries and accessibility features
Playing music? Controlling music when I'm not at my computer? What do you use for that?As someone with Sonos throughout their entire house (9 speakers and a sub). I wasn't even aware there was a problem and aside from setting up my system or adding speakers...I've never opened up the Sonos app.
I got a new phone 9 months ago and I realized I never even installed the sonos app. What are people using this for?
Playing music from my phone. Playing music from my music server.As someone with Sonos throughout their entire house (9 speakers and a sub). I wasn't even aware there was a problem and aside from setting up my system or adding speakers...I've never opened up the Sonos app.
I got a new phone 9 months ago and I realized I never even installed the sonos app. What are people using this for?
Yeap, that's why you rewrite different slices with test harness.There’s got to be balance here, lest you end up with Delta Airlines technology stack.
I just use the native apps I guess. I've never had a need to open the Sonos app after setting up the systemPlaying music? Controlling music when I'm not at my computer? What do you use for that?
Haven’t you heard? QA is a cost center. So you fire them all, and make the devs responsible for testing their own code with test harnesses that will have 100% coverage. Easy-peazy.Yeap, that's why you rewrite different slices with test harness.
With some of these apps, I doubt they have more tests than some QA testers
Ah the classic rewrite trap that any seasoned engineer will tell you to stay away from.
You should never rewrite the existing app. You replace parts of it at a time with testing to ensure you're not mucking things up
LOL, gee some really sensitive people downvoted you...too sensitive to be on the internet I would say. But yeah he should be the first to go at this point. He has been in charge during all the many issues with Sonos and people laid off. Besides it flat out not working the new UI is terrible too and I didn't really have complaints about the last UI when so many others did.fuck spence.
Sonos laid off all their US developers long ago and replaced them with cheap 3rd party contractors from 3rd world countires.I would be very interested to hear from someone on the inside exactly what happened here. Was the new app contracted out to the lowest bidder? Was it a matter of Sonos not wanting to pay the wages demanded by more capable developers? Is it a case of the cart pulling the horse, with designers and product managers having disproportionally more say in the product than the engineers? Perhaps marketing wanted the ability to inject their own changes without interacting with engineering which made for an unsustainable architecture? Some combo of all the above?
Lots of things that could've gone wrong here.
While this isn't a bad rule of thumb, rewrites can be pulled off with exceptionally capable teams and leadership that understand the value of everything the original was capable of and know to factor all of that into designs, requirements, and estimates for the replacement. Where things go awry is when the replacement isn't intended to be comprehensive or is based on a shallow grasp of the original. Extensive testing with real-world users helps a lot here too.
That's expensive though, and so is almost never what happens. It's way cheaper and easier to have the designers spin up a good looking mockup and build off of that.
Yeah, I was surprised at that as well. Not sure if it was the potty mouth, brevity, or Sonos Fandom, which has always struck me as a bit much. {shrug emoji}LOL, gee some really sensitive people downvoted you...too sensitive to be on the internet I would say. But yeah he should be the first to go at this point. He has been in charge during all the many issues with Sonos and people laid off. Besides it flat out not working the new UI is terrible too and I didn't really have complaints about the last UI when so many others did.
Sonos laid off all their US developers long ago and replaced them with cheap 3rd party contractors from 3rd world countires.
Like many others on this forum, it sounds like you and I both have experience in software development. It's been nearly two decades since I've seen any software company staff a formal QA department. Not having a QA department is quite normal in my experience. And while I agree there are risks to having devs test their own code, particularly during the initial phases of the no-QA transition, I have also seen many years of successful operations using the no-QA model.Haven’t you heard? QA is a cost center. So you fire them all, and make the devs responsible for testing their own code with test harnesses that will have 100% coverage. Easy-peazy.
What could go wrong?
Oh, no, they'll get huge raises. Look how much money they saved with all these layoffs!Multiple somebodies at the top of the company signed off on pushing these changes. They won't be fired, of course, but they signed off on it.
That has been my theory.Sonos hardware is too expensive and has too short of a life span.
Yeah, I was surprised at that as well. Not sure if it was the potty mouth, brevity, or Sonos Fandom, which has always struck me as a bit much. {shrug emoji}
I don't even know if this was a QA failure.Haven’t you heard? QA is a cost center. So you fire them all, and make the devs responsible for testing their own code with test harnesses that will have 100% coverage. Easy-peazy.
What could go wrong?
Generally true, but there are occasions where an app replacement could be necessary. Still, you better test the shit out of it to ensure functionality, and at least try to update the back end separately from the front end. (Sounds like Sonos did neither.)Ah the classic rewrite trap that any seasoned engineer will tell you to stay away from.
You should never rewrite the existing app. You replace parts of it at a time with testing to ensure you're not mucking things up