alt Hacker News> Which is why when folks nowadays say "you cannot use XYZ for embedded", given what most embedded systems look like, and what many of us used to code on 8 and 16 bit home computers, I can only assert they have no idea how powerful modern embedded systems have become.
Yet, I still need to wait about 1 second (!) after each key press when buying a parking ticket and the machine wants me to enter my license plate number. The latency is so huge I initially thought the machine was broken. I guess it’s not the chip problem but terrible programming due to developers thinking they don’t need to care about performance because their chip runs in megahertz.
Replies
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.
One of the more inspired design choices of the parking ticket devices in my area is the inclusion of a key repeat feature.
If you keep your finger on the touchscreen for just long enough, it helpfully repeats the keystroke while you're entering a license plate.
Given the inevitable hardware issues, this means that what should be a single tap frequently becomes a burst of identical characters.
The programmers who worked on this probably would've liked to be game developers instead.
Give it some slack, it's probably doing its best to inexplicably run windows.
That's programmer incompetence. Unfortunately pervasive, especially with devices like parking meters, EV chargers, and similar, where the feedback loop (angry customer) is long (angry customers resulting in revenue decrease) or non-existent.
Or maybe they think they should be sending each keystroke to a server and waiting for the response.
Everyone was locked out in a building am staying at (40 something stories) for several hours. When I asked the concierge if I can have a look at the system, it turns out they had none. The whole thing communicated with AWS for some subscription SaaS that provided them with a front-end to register/block cards. And every tap anywhere (elevators/doors/locks) in the building communicated back with this system hosted on AWS. Absolute nightmare.
Whilst I can not see a motivation I refuse to accept that parking machines are not advisarial design. Why do they have haf a dozen things that look a bit like tap n pay if they are not trying to make it eaiser for card skimmers.
It could also be intentional UX design. Or a result of the keyboard hardware.
Anything that makes the world worse for car drivers is a huge bonus for The planet.
And the self service kiosks/checkouts at supermarkets. So infuriating! Like I'd have to try to make something that slow myself on purpose!
Besides the fact that scanning a barcode seems beyond much of the general population, they do it so sloooow.
What can you expect, when people assume as normal shipping the browser alongside the "native" application, and scripting languages using an interpreter are used in production code?
Maybe that ticket machine was coded in MicroPython. /s
There's no pressure to make a good product because nobody making this decision has to use the machine. Everywhere I've worked purchase decisions are made by somebody with no direct contact to the actual usage, maybe if you're lucky they at least asked the people who need the product what the requirements are, otherwise it's just whatever they (who don't use this product) thought would be good.
"Key presses are 15x slower than they should be" gets labelled P5 low priority bug report, whereas "New AI integration to predict lot income" is P0 must-fix because on Tuesday a sales guy told a potential customer that it'd be in the next version and apparently the lead looked interested so we're doing it.