4 ms·

It’s an accessory. If we were talking about the speakers themselves, I wouldn be more sympathetic, but in this case I’m just not. The reality is that the natur

It’s an accessory. If we were talking about the speakers themselves, I wouldn be more sympathetic, but in this case I’m just not. The reality is that the nature of connected devices makes things different. This isn’t the same as a CRT TV (but also, look at how much it costs and how difficult it is get parts for a CRT in 2018). And like it or not, your next car won’t be as repairable as your current 15 year old car, because it will require custom software and bench access and updates that most mechanics will not pay for or maintain. At least these Sonos users have the option of not installing an update. This isn’t like Revolv where it just stopped working. The CR100 uses Flash IIRC...it is absolutely ancient. I’m not sure we should be realistically asking development teams to maintain separate code bases for old, obsolete software. Google and Amazon changed backends that made the CR100 stop working. Are you saying that that’s a travesty too? Legit question: how long should any company/service be required to add backward compatibility to old, obsolete products? I fundamentally agree that we should be building for longevity and serviceability, but that isn’t always possible. The platform and stack the CR100 was built on is not modern and cannot be easily maintained. And even if the software was open source (which would be great), that doesn’t change the fact that if the endpoints on the services it relies on change, nothing can be done. The only reasonable compromise I can see would be an update that would allow the CR100 to continue to work only with local files. Otherwise, at least users can opt not to update if they rely so heavily on a 13 year old controller.

TheSpiceIsLife 9y ago
Hmmm, yeah, it's tricky. And you're probably going to be right about the cars too.
wwweston 9y ago
> And like it or not, your next car won’t be as repairable as your current 15 year old car, because it will require custom software and bench access and updates that most mechanics will not pay for or maintain. Noting that the automotive market is increasingly opening itself up to the kind of obsolescence problems the software industry has never bothered to come to grips with (indeed, is to some extent actively against solving, from incentives at the business level to personal disinclination on the part of most programmers) isn't exactly a resounding counterpoint to worries about how software problems are affecting less crucial hardware devices. > Legit question: how long should any company/service be required to add backward compatibility to old, obsolete products? There's a point in here that's legit: perpetuity is a high bar, most products don't last forever. But there's also an extent to which this question is largely a dodge of the real question: what is "old"? Why do we accept or feel forced to accept a decade or shorter timeline? > we should be building for longevity and serviceability, but that isn’t always possible. The platform and stack the CR100 was built on is not modern and cannot be easily maintained. You know how we talk about code smells? (Or maybe we don't anymore, it was always a weird term and maybe it's so early 10s now). Pretty sure the word "modern" when it comes to software should be understood as a "thought smell." Every platform/stack any software is built on will be "not modern" by software standards in well under a decade, and is quite likely to grow more difficult to maintain over time. An acknowledgement of the value of longevity and serviceability doesn't mean much while implicitly accepting software-related value choices that mean longevity and serviceability remain not only difficult to attain but difficult to conceive of. > And even if the software was open source (which would be great), that doesn’t change the fact that if the endpoints on the services it relies on change, nothing can be done. If the software were open source, when endpoints change, the threshold for continuing utility is whether there's a developer out there somewhere who cares enough to work on it. Or could be made to care by consumers bearing cash.

TheSpiceIsLife 9y ago

Hmmm, yeah, it's tricky. And you're probably going to be right about the cars too.

wwweston 9y ago

> And like it or not, your next car won’t be as repairable as your current 15 year old car, because it will require custom software and bench access and updates that most mechanics will not pay for or maintain. Noting that the automotive market is increasingly opening itself up to the kind of obsolescence problems the software industry has never bothered to come to grips with (indeed, is to some extent actively against solving, from incentives at the business level to personal disinclination on the part of most programmers) isn't exactly a resounding counterpoint to worries about how software problems are affecting less crucial hardware devices. > Legit question: how long should any company/service be required to add backward compatibility to old, obsolete products? There's a point in here that's legit: perpetuity is a high bar, most products don't last forever. But there's also an extent to which this question is largely a dodge of the real question: what is "old"? Why do we accept or feel forced to accept a decade or shorter timeline? > we should be building for longevity and serviceability, but that isn’t always possible. The platform and stack the CR100 was built on is not modern and cannot be easily maintained. You know how we talk about code smells? (Or maybe we don't anymore, it was always a weird term and maybe it's so early 10s now). Pretty sure the word "modern" when it comes to software should be understood as a "thought smell." Every platform/stack any software is built on will be "not modern" by software standards in well under a decade, and is quite likely to grow more difficult to maintain over time. An acknowledgement of the value of longevity and serviceability doesn't mean much while implicitly accepting software-related value choices that mean longevity and serviceability remain not only difficult to attain but difficult to conceive of. > And even if the software was open source (which would be great), that doesn’t change the fact that if the endpoints on the services it relies on change, nothing can be done. If the software were open source, when endpoints change, the threshold for continuing utility is whether there's a developer out there somewhere who cares enough to work on it. Or could be made to care by consumers bearing cash.