Yes, but also from an implementation perspective: if I’m making code that might kill somebody if it fails, I want it to be as deterministic and simple as possible. Under no circumstances do I want it:
checking an external authentication service.
connected to the internet in any way.
have multiple services which interact over an API. Hell, even FFIs would be in the “only if I have to” bucket.
The argument the company makes is that it allows them to sell the device for cheaper upfront, which means that more people can afford to have one. They sell them for $400. But also fuck them, nobody ever died from HP disabling printers.
Also, if they genuinely wanted to make it more affordable up front in order to get the safety device in more hands, they could charge a chunk initially and then a regular payment plan for so many months. Not paying in perpetuity or we disable it.
It checks the service when booting up before a ride. After that it doesn’t connect to the internet. If you’ve gone past your grace period of 60 days it won’t boot up at all, and it will alert you that the device isn’t active.
Don’t get me wrong, I hate the idea of the subscription but it’s important to have accurate information. Did you even read the product page?
That information changes none of my issues; if you don’t see the plethora of potential implementation bugs involved, either you don’t code professionally or you shouldn’t be.
I code professionally, specifically I develop very resilient medical software. From a software perspective, as long as the developers are competent I have no issues with the device. There are so many other things you could take issue with when it comes to the vest, but I’m telling you software just isn’t one of them.
I’m sure the developers are competent, but the reason I care about the design decisions is the same reason the electric brakes on cars don’t interface with its infotainment system; the interface inherently creates opportunities for out of spec behaviour and even if the introduced risk is tiny, the consequence is so bad that it’s worth avoiding.
If you have to have an airbag be controlled by software (ideally the mechanism is physical, like a pull tab), it should be an isolated real time device with monitoring your accelerometer and triggering the airbag be it’s only jobs. If it’s also waiting to hear back from another device about whether your subscription ran out before it starts checking, the risk of failure also has to consider that triggering device.
It can be done perfectly, but it’s software so of course it has bugs.
Yes, but also from an implementation perspective: if I’m making code that might kill somebody if it fails, I want it to be as deterministic and simple as possible. Under no circumstances do I want it:
If the customer is dead, they definitely can’t renew.
Who wouldn’t tout your service if it saved them?
But also… why the fuck does this require a sub?
Because “fuck you, we’re rent-seeking and you can’t do anything about it,” that’s why.
The argument the company makes is that it allows them to sell the device for cheaper upfront, which means that more people can afford to have one. They sell them for $400. But also fuck them, nobody ever died from HP disabling printers.
Also, if they genuinely wanted to make it more affordable up front in order to get the safety device in more hands, they could charge a chunk initially and then a regular payment plan for so many months. Not paying in perpetuity or we disable it.
It checks the service when booting up before a ride. After that it doesn’t connect to the internet. If you’ve gone past your grace period of 60 days it won’t boot up at all, and it will alert you that the device isn’t active.
Don’t get me wrong, I hate the idea of the subscription but it’s important to have accurate information. Did you even read the product page?
That information changes none of my issues; if you don’t see the plethora of potential implementation bugs involved, either you don’t code professionally or you shouldn’t be.
I code professionally, specifically I develop very resilient medical software. From a software perspective, as long as the developers are competent I have no issues with the device. There are so many other things you could take issue with when it comes to the vest, but I’m telling you software just isn’t one of them.
I’m sure the developers are competent, but the reason I care about the design decisions is the same reason the electric brakes on cars don’t interface with its infotainment system; the interface inherently creates opportunities for out of spec behaviour and even if the introduced risk is tiny, the consequence is so bad that it’s worth avoiding.
If you have to have an airbag be controlled by software (ideally the mechanism is physical, like a pull tab), it should be an isolated real time device with monitoring your accelerometer and triggering the airbag be it’s only jobs. If it’s also waiting to hear back from another device about whether your subscription ran out before it starts checking, the risk of failure also has to consider that triggering device.
It can be done perfectly, but it’s software so of course it has bugs.