Comment by teraflop | Hacker News Reader

Comment by teraflop | Hacker News Reader

The "normalization of inexplicability" is indeed infuriating. It has always been bad when it comes to computer software, and it's increasingly creeping into other consumer products that depend on embedded software.

I bought a new electric car recently. For the most part I've been quite happy with it. Shortly after I bought it, it started popping up a warning message saying "check EV system" every time I started it. By the time I brought it into the dealership, the warning had gone away, and the technician just told me something to the effect of "eh, I guess it just does that sometimes, let us know if it happens again." Hardware fault? Software bug? Who can say?

Like most modern cars, it has connectivity and Google Maps built into the infotainment system. The vast majority of the time, it works fine. Sometimes it says it has no connectivity (meaning no traffic data and suboptimal routes) for the duration of a drive, even in areas with a strong cell signal where it normally works fine. Sometimes the car says it has connectivity, but Google Maps still thinks it's offline. Sometimes Maps will actually load and display a route, but the "start navigation" button just spins forever as though it's still waiting for something. Are these related issues? Is there a common cause that might be fixable? Who can say?

(Conveniently enough, the warranty specifically does not cover any failures of software or firmware to operate correctly.)

My Kia Niro EV, which I'm otherwise quite happy with, has an occasional failure mode where it locks out the ignition for an arbitrary amount of time (generally 15 minutes). It's sometimes, but not exclusively, triggered by scheduled departure turning on the AC. Kia's response is a big shrug...

I remember twenty years ago trouble-shooting my father's Internet connections and not being able to discover the misconfiguration. Once I called the technician and they knew nothing but "wade down to this dialogue and choose 'reset'". That didn't work either - but it was a distinct moment in me noticing the Internet and software becoming opaque. And it was only gotten - sometimes those moments of opaque failure are transitory but sometimes they stay indefinitely. Currently, my android phone can't see group texts created by iphones. I'm thankfully semi-retired enough for this to be a blessing but it could a crisis for someone else (I know a couple that fixes the problem temporarily but a text isn't something you want to spend hours debugging to get if you need it).

But my point - this has been increasing for quite a while and it's something like the evil twin of the "it just works" school of design. Because when the default expectation is "just working", the failure mode is "it just doesn't work". I mean, the default assumption that users are morons has de facto made us all morons since we can only deal with the "interface made for morons" and makes failure into opaque failure.

It's world the developers know "all abstractions are leaky abstraction" but where developers still won't give users (or even downstream developers) tools to deal with the leaks 'cause a simplistic interface matters more.

"When there's no emergency exit, there can't be an emergency, can there?"

Late Douglas Adams noticed this phenomenon decades ago:

> The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.

There's that, but even he didn't note "now, soon nearly everything is going to be in that category of things that can't possibly go wrong"

I think some of it is an unintended consequence of the backlash against bad or puzzling error dialog boxes in '80s and '90s software. A lot of people seem to have concluded that the easy solution to the challenges of error reporting was just to fail silently instead roll_safe.jpg .

Or to display "something went wrong - oopsie daisy! Try again later! Our team of highly trained monkeys have been summoned to work on the issue immediately!" which is not confusing at all (except the last part) but also provides no value.

> a warning message saying "check EV system"

These are some of the most annoying messages a piece of software can possibly display, and I hate them with a passion!

It's like this with a lot of commercial software, where designers don't want to scare users with complicated (useful) error messages, so you just get a "whoopsie! Something went wrong".

I'd much rather have an error message that I _don't_ understand over an error message I _can't_ understand.

In the case of cars, it used to be that a generic "Check engine" light showed up on your dash, and you needed an external tool to ask the computer what caused it to light up, but why would that be nessecary in a modern vehicle? You've got a large, high resolution display (or more!) on the CAN bus, why can't it show the full problem so you could take a picture right as it happens and send it to your dealer for instant diagnosis?

Even if the user error is opaque, why not log a short internal error to flash or the cloud?

I had a similar argument around web-facing feature recently. The question was how much detail to show the consumer on an error indicating the network was down or unreliable.

My stance was that far too many of our support tickets involve someone taking a screenshot, and we'd want that information in any such screenshot... Especially if the network was so bad that it couldn't reach us any other way!

>why can't it show the full problem so you could take a picture right as it happens and send it to your dealer for instant diagnosis?

Fault codes are uploaded to the manufacturer on modern cars with telematics. On mine, the app will say you have an engine fault (or need an oil change or recall) and offer to schedule an appropriate appointment. If you call them, they often have it already in their portal under your VIN. The manufacturer also keeps track of these for regulatory purposes (triggering recalls).

A single fault code doesn't mean much. That's like saying I got a segfault, please fix my problem. You need a stack trace, registers, what the user was doing at the time, whether they can reproduce it, etc.

OBD2 stores a _freeze frame_, most of its readings at the time of the fault. You also need to look at other fault codes, pending codes, frequency/history of the fault to make a diagnosis. In any case, you can't just give one code; it's 5 pages of readings.

Reply on news.ycombinator.com