You are viewing a single thread.
View all comments
104 points

It reportedly checks subscription upon putting the vest on and supposedly won’t turn off mid ride.

permalink
report
reply
240 points

And if there’s a bug in that code, you’re fucked.

Safety features should work if everything else fails. Their failure mode can’t be “fuck it, it didn’t work”. Which is directly opposite to the failure mode of a subscription based service.

permalink
report
parent
reply
105 points
*

This is why:

  1. The FTC needs to do its job and start outlawing all these obscene subscription business models for things that are rightfully products, not services. Where’s my goddamned First Sale Doctrine, FTC?!

  2. Software Engineers working on commercial products need to be professionally licensed, so that proper consequences can be applied for unethical “fail-deadly” designs like this one.

permalink
report
parent
reply
64 points
*

As a software engineer, the thought of my code being responsible for someone’s safety is fucking terrifying. Thankfully I’m not in that kind of position.

From experience though, I can tell you that most of the reasons software is shitty is because of middle or upper management, either forcing idiotic business requirements (like a subscription where it doesn’t fucking belong!) or just not allocating time to button things up. I can guarantee that every engineer that worked on that thing hated it and thought it was fucking stupid.

Licensing would be overkill for most software as it’s not usually life and death. I think in this case since it’s safety equipment it really should have been rejected by NHTSA before it ever hit stores.

permalink
report
parent
reply
11 points

This is managements fault, not the engineers fault.

We have to implement the requirements we are given. If we don’t, we get fired and they hire someone else who will do it.

permalink
report
parent
reply
7 points

My dad worked for AAA. Once he got a call because a lady’s car errored out and thought she didn’t have her seatbelt buckled mid-drive, so it shut the engine off. On the freeway.

Even without a subscription, failsafes should always fail safe.

permalink
report
parent
reply
5 points

Thorium reactors have a cleverly dumb failsafe. If reactor control fails, there’s a plug that melts and drains the contents into a container that’s not fit for runoff neutron generation.

That’s an example of a failsafe that fits its purpose. It’s still possible to fuck it up, but it would take a lot of effort to do so.

permalink
report
parent
reply
5 points

Pop verification neck to continue.

permalink
report
parent
reply
2 points

And if there’s a bug in that code, you’re fucked.

If there’s a bug in your car’s airbag, you’re also fucked.

permalink
report
parent
reply
61 points

The problem is the subscription, not how it was implemented

permalink
report
parent
reply
55 points

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:

  1. checking an external authentication service.
  2. connected to the internet in any way.
  3. have multiple services which interact over an API. Hell, even FFIs would be in the “only if I have to” bucket.
permalink
report
parent
reply
26 points

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?

permalink
report
parent
reply
1 point

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?

permalink
report
parent
reply