[lallysingh]

My first guess was debouncing. They assume that the switches are worn out, deeply weathered, and cheaply made. Each press will cause the signal to oscillate and they're taking their sweet time to register it.

When the device is new this is an absurd amount of time to wait. As the device degrades over 10, 20 years, that programming will keep it working the same. Awful the entire time, yes, but the same as the day it was new.

[scrumper]

I was late for a train at my local station and the parking machine was taking ages to respond to keypresses. I could see the training pulling up to the platform and I was still stuck entering the second digit of seven. In my shameful frustration I hit the machine fairly hard. While the button presses might take a while to register, the anti-tamper alarm has really low latency and is also quite loud.

[bluGill]

You need to find the right person to complain to. Here we are sympathetic, but can't do anything.

The right person is the other riders on the train - but the hard part is to frame this such that they join you on a march to the the agency that owns that machines to complain. I wish you the best of luck figuring out how to do that (I don't know how to do it - and if I did there are might higher priority things that need to be fixed).

[scrumper]

Well it was six years ago, I work from home now and take the train once a quarter, and they've augmented the machines with app parking now so I have nothing to complain about anymore :)

[ssl-3]

Debouncing would be smart, sure. But sometimes, these sorts of embedded machines are weirder than that.

At Kroger-brand gas stations near me, I get to interact with the buttons on gas pumps to select options and enter a loyalty ID.

Those buttons have visible feedback on a screen, and also audible feedback consisting of a loud beep. And there's always delays between button press and feedback.

Some combination of debounce and wear might explain that easily enough.

Except... the delay between pushing a button and getting feedback is variable by seemingly-random amounts. The delay also consistently increases if a person on the other side of the pump island is also pushing buttons to do their own thing.

It's maddening. Push button, wait indeterminate time for beep, and repeat for something like 12 or 13 button presses -- and wait longer if someone else is also using the machine.

I can't rationally explain any of that variability with debounce.

[lazide]

They are running it on a Java VM in a container - on a 386?

Over WiFi?

[ssl-3]

Perhaps.

Or perhaps the original programmers skipped the class on concurrency 25 years ago, and nobody has subsequently bothered to pay anyone to update that part of the software.

[QuercusMax]

One time I decided to test whether these grocery story loyalty card XX cents off per gallon transactions were properly isolated, when my wife and I were both filling up vehicles at the same gas station at the same time. We both got the $0.50 discount per gallon with no problem. I'm sure there are lots of creative ways you can exploit the poor design of these things.

[philipallstar]

That's a good point. When I use them I assume they're making API calls to a central server to validate (or something) them.

[Schlagbohrer]

Making API calls to a server to do button debouncing does sound like something so stupid a tech company would do it

[bigfishrunning]

in the worst case, they don't know they're doing it, because they've called some 'debounce.js' microservice wrapper and haven't audited it