“Weigh your… pancakes… move your… pancakes…”

May 7, 2010 6:56 AM

Why are ATMs and similar machines (gas pumps, self-serve checkouts) so damn slow?

I realize at various points in the transaction there are database look-ups over a WAN, and I understand these things take some time, but I’m taking about screen refreshes or just allowing me to press the “next” button. Simple things that happen instantly on my iPhone or desktop PC seem to take forever (ok, a couple extra seconds) on these machines. It seems like these things move painfully slow during every point of the process, even points of the process that should happen instantly. Debit or credit? Wait… Enter Secret Personal Identification PIN Number… wait… select grade… wait… lift handle… wait… start pumping… wait.

Curiously, the self-serve ticketing thingy at the movie theater works the way I would expect. I stick my card in, I press a few buttons, screens refresh instantly, and I have my tickets in a matter of seconds with no irritating pauses.

My theories are:

1) Slow, low-cost CPUs. This would make sense but even the 2Mhz 6809e in my TRS-80 back in 1986 could jump to the next screen instantly when I pushed a button.

2) There are pauses built-in to slow them down because most consumers find it hard to keep up with computers. This might have made sense in 1988 but not in a time when everyone has more CPU power on their phone.

3) It communicates back to the mothership more often than I think, hence the frequent pauses.

4) They're not that slow. I’m just an impatient Masshole with ADD and I should learn to relax.

5) All of the above.

I hope this isn’t coming across as chatfilter. I seriously get irritated every time I’m at the grocery store or gas pump and I’m curious why they don’t do more things instantly the way just about every other computer in the universe does. Just move to the next screen, dammit.

posted by bondcliff to Computers & Internet (32 answers total)

I know the programmers out there will probably complain about this explanation, but I blame shitty software.

Yeah, they are probably using the least expensive hardware they can, and there are presumably a lot of constraints because of the "hardened" nature of the machine.

But you are right- a properly done UI should react more quickly.
posted by gjc at 7:03 AM on May 7, 2010 [1 favorite]

I think you've mostly got it covered.
A few additional thoughts:
Shared resources, all the machines in a particular facility have to share one connection.

They probably only pay for the cheapest/slowest connection they can get away with.

Electronics ruggedized for high reliability in an outdoor environment are never the fastest possible.

It takes time to certify/debug things for this sort of use; you really need to be confident that they aren't going to screw up in some awful way. This causes the manufacturers to be reluctant to change from the tried and true.
posted by Confess, Fletch at 7:04 AM on May 7, 2010

3) It communicates back to the mothership more often than I think, hence the frequent pauses.

I believe many communicate back to "the mothership" via dial-up or ISDN (and many of these establish a new connection each time).

Presumably, they use some sort of private-key encryption or one-time pad to make this more secure than it sounds (private-key encryption is tough to break -- it'd be easier to just rob the bank outright)
posted by schmod at 7:06 AM on May 7, 2010

Many of those systems also run Windows CE, which is a piece-of-shit operating system. And many of those systems need to be able to run without a fan or other active cooling, so they necessarily have to run really slow, lame processors.

But mostly, I think it's poor programming.
posted by fake at 7:11 AM on May 7, 2010

Electronics ruggedized for high reliability in an outdoor environment are never the fastest possible.

Oops, Confess, Fletch already covered that.
posted by fake at 7:11 AM on May 7, 2010

Response by poster: Louis CK on your problem.

Don't get me wrong, I love the fact that I can buy my Crisco and Wheat Thins without involving a retail monkey at the Stop and Shop, and I'm continually amazed at the technology surrounding me, I'm just curious why my home PC knows that a 12 year old in Hong Kong fragged me with a plasma gun .000003 of a second after it happened but I have to wait 1.5 seconds for the "finish and pay" button to not be grayed out.
posted by bondcliff at 7:15 AM on May 7, 2010 [5 favorites]

They are definitely using much older technology in terms of hardware and network gear. They are a conservative bunch and as such new technology is rigorously tested before it is certified for use.

With that said, people could do amazing things even with the hardware back in the 70s/80s if they really wanted to. What this comes down to is it not being a priority or a skillset that the ATM developers have. This is usually the case that you have a bunch of hardcore guys who understand accounting based programming along with crypto. The most junior person gets to write a few screens that capture and present data. This just hasn't been a priority. That coupled with the long lifetimes of these machines means that change is slow to happen everywhere.

I will say that over the last 18-24 months I have seen marked improvement in some ATMs and self-checkout computers at grocery stores whereas the computer at the garage at work still uses a speach synthesizer that sounds like something out of 1970s science fiction (the voice also slows down tremendously while the machine is trying to authorize a credit card).
posted by mmascolino at 7:19 AM on May 7, 2010

ATMs and gas pumps are not designed to optimize the experience for someone who is comfortable with computers and is used to interacting that way. They are designed for the bottom half of the population, the ones who might have trouble keeping up if the screen changed after 1/2 second rather than after a full second. The delays are intended, and probably represent the tradeoff between whether the least capable people can use the machine, and whether the most capable will stalk off in frustration.
posted by logicpunk at 7:23 AM on May 7, 2010 [2 favorites]

Back in the day, one of my Highschool buddies got an internship working for a company that developed software for ATMs. I have no idea whether he was just pulling my leg, but he had said that there was actually a delay added to the code as opposed to the transactions actually taking that long.
posted by jangie at 7:35 AM on May 7, 2010 [1 favorite]

Louis CK is great, but that was a rude way to "answer" your question.

Where I live, a new law made prepaying for gas mandatory. Unless you want to go into the cash register, hand over your debit card or DL, and then trek back out to the pumps, you're stuck using the debit payment option on the pumps here. It's sloooooow.

I figured it's because the software and hardware are usually pretty old. They're also trying to upsell you to car washes etc.
posted by KokuRyu at 7:36 AM on May 7, 2010

Best answer: I'm just curious why my home PC knows that a 12 year old in Hong Kong fragged me with a plasma gun .000003 of a second after it happened but I have to wait 1.5 seconds for the "finish and pay" button to not be grayed out.

The cost of a bug in MMORPG is that some people have to start their game over. The cost of a bug in an ATM machine is potentially millions of dollars lost, credit card numbers compromised, massive lawsuits initiated.

The game company can rev their software every week if they want to. Heck, they could rev it every day. The ATM company probably revs their software every six months or a year. They need to be much, much, much more conservative about introducing changes.

I'm not saying that the ATM companies use good software development methodologies. All indications are that they don't. But they have at least been able to keep the bottom line transactional capabilities of their applications relatively sound, and that it, so to speak, their bottom line. Everything else is secondary.
posted by alms at 7:44 AM on May 7, 2010 [1 favorite]

Machines that take money are *always* more efficient than machines that give money. To test that theory, go to your nearest laundromat and compare the bill changer to the soda dispenser. Make sure you use a wrinkled bill. Draw your own conclusions.
posted by Ys at 7:45 AM on May 7, 2010 [3 favorites]

I think it's a combination of shitty design-by-committee, and clueless users.

I'm reminded of DNA's line about how people trying to make things foolproof often underestimate the ingenuity of common fools.
posted by SansPoint at 7:49 AM on May 7, 2010

-As a company, you can't update every Point of Sale(POS) system/device at every incremental improvement in transaction speed. Its not cost effective. Meaning, you use a system until it has to be upgraded or is scheduled to be upgraded.
-Similarly, you can't update every POS hardware platform when there are improvements to infrastructure, especially if infrastructure improvements are not even throughout the area serviced. Meaning that in rural Vermont where there is still dial-up in some areas (yes, dial up at the pump), it doesn't make a lot of sense to roll out higher bandwidth support in some wide swaths.
-Transaction speeds take a while. There are a lot of credit cards. Even on state of the art systems from direct sales (a la telemarketing) it can take a few (3<>t <1> -Usability study theory: If you can speed up one section of the experience, but you can't speed up the next, you (unavoidable) speed.
posted by Nanukthedog at 8:15 AM on May 7, 2010 [1 favorite]

I have to strongly disagree with those who said ATMs are slow because of bad software development, or lazy programmers, or a lack of knowledge by said programmers. This is a machine that sits in a totally unsecured location and can dispense cash; yet because it's not as responsive as your home pc it must be because the programmers don't know what they're doing?

The reason it's slow is so that users don't get ahead of themselves when performing bank transactions, and also as a security measure, to prevent both brute force and timing attacks.
posted by unrulychild at 8:16 AM on May 7, 2010 [3 favorites]

There's another factor which you haven't mentioned. I see a noticeable difference in Gas Pumps computers in summer vs. winter.

Summer is tolerably slow, but in winter when the temperature hits -40C/-40F, even the screen refreshes can take 5 seconds or more. Not to mention the actual beeps that get emitted slow right down in the cold. Beeeeeeeeeeeep. Beeeeeeeeeeep.

Perhaps they're designed at different temperatures than they operate?
posted by blue_beetle at 8:24 AM on May 7, 2010

To give you an idea what kind of software some of these things are running, Microsoft only discontinued sales of Windows 3.11 for embedded devices in November 2008.
posted by 6550 at 8:37 AM on May 7, 2010

I've noticed that the software in the gas pumps in my area (northern VA) have gotten incredibly slow in the last year or two - they used to be standard ATM speed, but now it can take several seconds just to get all the buttons to finish displaying on the screen, and a couple more before they start responding to touch. It doesn't look like the interface has changed, it's just sluggish as all hell now..
posted by FatherDagon at 9:08 AM on May 7, 2010 [1 favorite]

If you had grown up in the era when people hauled out their checkbooks every time they wanted to buy something - which involved the cashier stamping the back of the check, copying numbers from various ID, and running the check through a special printing slot on the register - you'd never even *think* about complaining about a several second pause for transaction card approval. ;-)

That said, I would imagine it's the connecting with third-party security apps somewhere that keeps it from being instantaneous, and over the years I have noticed that nationwide shopping traffic affects local approval speed (payment approval is notoriously slower on holidays and in the week or so before Christmas).
posted by aught at 9:35 AM on May 7, 2010

The reason it's slow is so that users don't get ahead of themselves when performing bank transactions, and also as a security measure, to prevent both brute force and timing attacks

If that were true, wouldn't my bank website be super, super slow as well?
posted by pjaust at 9:43 AM on May 7, 2010

Also, anything that's installed (like an ATM or a gas pump POS) was probably installed a long time ago, maybe back when the technology was new, which means that unless a hardware update has been done, you may be using 15+ year old hardware. Think about how fast computers are now vs then.

And that same hardware may be running much much newer (and more demanding) software, since updating the software is logistically much easier/less expensive.
posted by Four Flavors at 9:45 AM on May 7, 2010 [1 favorite]

There are processors that are a lot slower and cheaper than a 6809 - that is pretty high-end for an 8 bit CPU. The Freescale 68HC08 series only has 8 bit registers and one accumulator, so any kind of non-trivial math takes a lot of instructions. I also image that there is a lot of network traffic going on that slows things down.
posted by rfs at 9:46 AM on May 7, 2010

I really haven't noticed ATMs being slow. In fact, the oldest machines (that usually actually run OS/2) are usually the fastest.

But self-checkout machines? Pure torture, each and every one of them. It's not the money processing part, which is actually decently fast. It's the scanning/put in bag cycle. It's ridiculously slow and laggy. It goes: wave item in front of the scanner. There's a lag of a few seconds, then *beep*. Then another lag. "Please put this item in the bag." Ok, put the item in the bag. Another lag as it weighs the bag to make sure you're not stealing stuff. Then it starts all over for the next item you scan.. There's no excuse for this laggyness and slowness, aside from possibly the weighing lag: the machines that the checkers use are very fast, and probably are older and have slower CPUs than the self-checkouts. *beep* *beep* *beep*.

It has to be bad programming or just shitty design.
posted by zsazsa at 10:24 AM on May 7, 2010 [1 favorite]

A couple of thoughts. ATMs only connect to the bank once you've entered all the information. That is, the connection isn't made until after you've entered your PIN, selected withdraw from checking, $40, No Receipt, etc. So there no lag coming from waiting for a network response there.

Most ATMs at a retail location connect via an old-fashioned modem. Sometimes you'll come across a machine with the dialer volume left on, and you can here the familiar sounds of a modem connecting. I believe that most connections are done at 1200 Baud because it would actually take longer to to go through the hand-shake process needed for a faster connection than it takes to transfer the data needed to process your request.

I agree with the people saying the interface is slow on purpose. I recently helped my mother-in-law with an ATM and it kept trying to time out on her because she was taking too long reading the menus.
posted by Eddie Mars at 10:36 AM on May 7, 2010

Most of these things are communicating at 1200-9600 baud over serial bus. This is by design because the most important requirements for these machines, which may be used by thousands of people a day and are located in areas that may be hard for techs to service on-site, are that they be simple, rugged, and cheap.

Remember 9600 baud over dial-up? Anyone? Bueller?
posted by word_virus at 10:43 AM on May 7, 2010

Some of these terminals just seem to have weak processors - there's a Chevron gas station near me with the fairly standard LCD display for credit card payment. But at the end, when everything is done, it can take 10/15 seconds of standing their like an idiot, waiting, wondering for it to finally ask "Do you want a receipt".

And the display often has the fluttery feel of a dumb network terminal somehow - that there is only one processor for the whole bank of gas pumps and it's being timesliced to handle them all.

I haven't cared enough to test my theory and see what happens if I'm the only one getting gas (is perf any better?), but I can't think of any 'by design' reason for this crappy performance, as at a busy gas station, they'd want to get people out of there as quickly as possible.
posted by Berkun at 10:51 AM on May 7, 2010

I worked in network operations for a large regional bank. One of our responsibilities was monitoring the ATM network, as well as all the ATMs themselves, and calling out technicians when they were offline.

I mention this only to tell you that you would be SHOCKED at how many ATMs still in active use run OS2.
posted by namewithoutwords at 11:04 AM on May 7, 2010

For the self-checkout at the grocery store, my issue was the speed/accuracy of the touchscreen interface. It seems to take forever to press a button on the screen and have the computer accept it. Often it never registers that I have touched it, leading me to wonder if my hands are too cold or if I'm not really human (Hath not a Jew eyes? hands, organs, dimensions...? I'm HUMAN TOO!). Ask my daughter - she saw me throw a package of handtowels over my shoulder at Walmart (Forget it! We don't need these!) because I was so frustrated trying to get it to notice the transaction. Ok, that was a barcode issue, not a touchscreen, but it shows my level of anger.

Anyway, the cashier at Kroger told me a trick: turn your hand around backward and use the back of your fingernails to touch the screen. OMG it works great!
posted by CathyG at 11:47 AM on May 7, 2010

I think its because most atms still use modems. They have to dial out first anbd connect then have to wait for the data.
posted by majortom1981 at 12:27 PM on May 7, 2010

If that were true, wouldn't my bank website be super, super slow as well?

Only during the authentication phase. But it's not as important, because your computer doesn't dispense cash.
posted by unrulychild at 1:23 PM on May 7, 2010

Best answer: I used to be a software developer at an ATM company. I don't think we were particularly lazy or bad programmers. Writing software which interacts with complex, failure-prone physical devices and has to run unattended 24/7 is hard.

Some ATMs are slow because they use very old hardware — and yes, there are lots of ATMs which still run OS/2.

Newer ATMs can still struggle when banks require that they show fullscreen AVI or Flash advertising movies. Often banks require them to run antivirus too.

But brand new ATMs tend to run Windows XP and have a reasonably recent CPU. Their UI is often based on Internet Explorer rendering HTML pages from local disk. Why do these still end up feeling slow?

I think the answer is the amount of interaction that is required with physical devices at each stage. An ATM is made up of a number of physical devices, connected via serial or USB ports: the card reader, cash dispenser, pin-pad, receipt printer, etc. All of these devices have an array of sensors to determine aspects of their current state. For instance, a receipt printer would have sensors to detect if it is jammed, if it is full or low or out of paper, if it is out of ink etc. This is for the simplest device — the more complex cash dispenser has multiple components and thousands of possible states.

Each stage of a transaction requires the software to have a good idea of what state the devices are in. For instance, if the receipt printer is jammed, you should hide the button allowing the user to request a receipt. If the cash dispenser has $20s but is out of $10s, you can only allow the user to withdraw multiples of $20. Determining the state of a given device takes time because the physical sensors take time to determine their state and report back. A huge number of these slow checks, some of which are conditional on the results of other checks, have to take place between the user pressing a button and the ATM showing the next screen.

On top of these UI-driven checks, the software must regularly poll the devices' sensors to check they are OK. Mostly, devices are not smart enough to simply send an unsolicited alert to the software when something goes wrong.

The vast amount of checking required to keep the software in sync with the hardware is necessary not only to keep the UI up to date, but also to avoid bringing the ATM out of service by sending an invalid command. For instance if the card reader temporarily jams, the ATM needs to detect this, stop the transaction and run the device's reset routine, which might clear the jam. If the jam isn't checked for, and the ATM goes on trying to accept cards, the card reader could become unrecoverable and a technician would need to come and fix it. Until she arrives, the ATM is out of service and the bank is losing money.

This is an answer from a technical perspective — a higher-level answer would be that user experience is compromised because banks value it less than 24/7 unattended availability.
posted by matthewr at 1:20 PM on May 8, 2010 [4 favorites]

I come to this from the perspective of a Software Engineer who did 18 months of Microelectronics. I'm only going to address non-critical systems, because technology makes banks scared and that's the root cause of making everything super-hardy there.

Where it comes into play in ATMs is, I believe, multi-facited and complex, but boils down to two things;

A: Shitty Development Processes
B: Tightarsedness


First, SDP. Bad business analysis can produce software that only reflects the needs of some of the stakeholders, or only some of those needs so in the end no-one is happy. Perhaps they had a requirement "Don't move too fast for elderly persons" based on an assumption that that would frighten them off, not realizing that frustrates everyone else.

Perhaps the developers didn't care about their application, and so didn't pay any attention to speed.

The design of the app might be so terrible that it is UNABLE to be compensated for by developers. A common pattern goes BA Makes Decision On Use Case, Architect with no insight into use of product goes overboard with unhelpful architecture, Developers who Have UI Experience complain and are ignored because their business card doesn't say BA or Architect, user gets terrible experience. It's not nesscessarily a failing of anyone involved, just that the culture is you're responsible for what you're told, and don't get input into anything else. So the Architect's design doesn't give the programmers the flexibility to implement good systems. The BA's use-cases ignore some usability. Some use-cases are shortcut because the Devs don't fully understand them. And so on.

Shitty process is ENDEMIC in the kinds of companies who make these integrated systems. It's basically the rule. It sucks and why no Software Engineers should be proud of their profession yet... We have a long way to go.

As for B, this can be from a couple of perspectives. First off, most developers of the kiosks themselves RAPE their customers on price. You know that slow kiosk with the Pentium 3 and 256Mb of RAM, a 16 colour 14" CRT and a single, slow laser scanner? Could easily cost $3000. That would buy you FIVE laptops of much better performance. But there isn't really an option because all the kiosk manufacturers charge around the same. Why? 'cause the companies building these products don't also want to support the kiosks, the software is difficult enough.

Secondly, the organisation buying the finished product will pay 10x$3000 for their terminals, but if they WANT a decent machine they might have to pay 10x$7000. Suddenly their project is a lot more expensive, and it's easy to say "Well, people will find the convenience of using the system FAR outweight the speed. There will be ten terminals, no-one will have to wait in line!" They may even have no idea what those speeds mean on a practical level.

Yes, it SUCKS. Bigtime. And could be fixed, if the involved parties wanted too... But they don't.
posted by Quadlex at 5:52 PM on May 9, 2010