7 ms·

Uber Eats' Swapped Order Problem

34 points by fahhem 4y ago

deleted 4y ago
[deleted]
justrealist 4y ago
This is conditional on there being 2 simultaneous orders, right? If there's a single pickup per restaurant at any given time, the odds are 0, not .02%.
- orlp 4y ago
  Yes, but conversely if there's 10 simultaneous orders the probability is 1 - (4095/4096) * (4094/4096) * ... * (4087/4096) = 1.093% to have a collision with a code consisting of 3 hexadecimal characters.
blendergeek 4y ago
Perspective of an Uber Eats Driver: Things may be a bit more complicated than this simplistic blog would suggest. Every restaurant seems to have its own receipt format. Some don't have a name field and uber puts it in the "phone number" field (eg instead of "Name: Arianna" you see "Phone: ARI-IANN-A". Uber has certain information they need to give the restaurant (its different for each one). The receipt has certain fields (these don't match up all the time). It isn't a simple matter of an identifier that can be fixed.
totetsu 4y ago
I feel like the silly factor in reading phrases like 'abstract century' would be a problem if you are reading them or listening to them all day. Like a kind of having abstract poetry foisted on you. Then also take into account the amount of people in the gig-delivery / restaurant business for whom English is not a first language, and may not have matching understandings of letter sound equivalencies, it might be a bit uncomfortable.
- blowski 4y ago
  It’s similar to what3words and that seems to be working fine.
  - arrow7000 4y ago
    Does it? Who uses it?
    - blowski 4y ago
      Quite a lot of the UK police, ambulance, and fire services are using it. I also had a taxi company using it recently.
      - feintruled 4y ago
        It's not without its problems. Mountain Rescue services actively try to discourage its use. https://www.grough.co.uk/magazine/2022/08/31/dont-rely-solely-on-what3words-app-say-lakeland-rescuers-sent-to-wrong-side-of-lake https://www.grough.co.uk/magazine/2022/08/31/dont-rely-solel... This is relevant: https://cybergibbons.com/security-2/why-what3words-is-not-suitable-for-safety-critical-applications/ https://cybergibbons.com/security-2/why-what3words-is-not-su...
  - throwaway426079 4y ago
    I can't think of a context where a new w3w is being verbally confirmed every couple of minutes, which is what would happen in a busy restaurant.
    - blowski 4y ago
      Yeah, I don't think the concept works in this case because it's too noisy. But I don't think it's "silly". Everything's silly until it becomes normal.
ZiiS 4y ago
You need to account for the number of simultaneous orders so the maths is wrong. If the is a problem then Uber can just discard order numbers for the same resterant, same day, and same first three digits.
- f_allwein 4y ago
  That’s what I thought - if you order for pick-up at a restaurant, you get a pickup number consisting of two or three digits. That’s not a problem since there aren’t 100 people waiting to pick up at the same time. So Uber could switch to „Uber Eats 1“ etc, right?
Kwpolska 4y ago
"abstract century" is a terrible order ID. It doesn't look like an order ID, which can be confusing and will require more training. It's two English words, which might be difficult for non-English speakers (Uber Eats is an international service, and the restaurant staff and the courier might not share a common language). Also, what if the random two words end up being "include cutlery"? A better set of characters and ensuring that two order numbers in the same restaurant are very different would be a much better solution.
- londons_explore 4y ago
  I had to set initial passwords for ~100 users of a computer system. I chose two random dictionary words for each user. I had ~5 complaints that I had deliberately picked an insulting password for a user. It turns out that two totally random dictionary words is offensive a surprisingly large proportion of the time. Eg. 'tiny boots', 'hairy moustache', 'gray face', etc.
  - marzipanWhale 4y ago
    If someone called me 'tiny boots' I'd just assume they were comparing me to Caligula
  - londons_explore 4y ago
    the funniest was some bloke who really didn't like people making fun of his orange hair... And the random password was "flaming top".
namaria 4y ago
This is a great example of "code tunnel vision". I see it in a lot of developers. They see a problem in the real world and they think "this could be fixed with this snippet of code". Ignoring all the incredibly complex context of running large scale services in the real world: organizational issues, politics, infrastructure, operations, maintainability, etc etc. "It's so fixable! Here are 150 lines of code that solve the problem! How come it exists?" If only everything could be fixed by a pull request.
- islon 4y ago
  Every problem is trivial when you don't understand it.
- raverbashing 4y ago
  True. Also their solution has a lot of minor problems as well Upper case letters are harsh when on a big text, but for the case in point they're perfect And no, nobody will shout "abstract century" in a McD, it doesn't make sense. Some delivery apps show the order no. in big letters on the phone, so it can be shown to an attendant, not sure Uber does that, but of course that doesn't work with your 'smart' solution Maybe this is an exclusive Uber problem, maybe because they focus on drivers picking up more than one order
  - namaria 4y ago
    That is precisely the problem. You have hundreds of people solving problems with colliding visions and myriad unforeseen issues that need to be addressed. Compromises emerge. There will always be someone who can't discern that their imagination leaves out great many details thinking that they have superior insight.
- mathieuh 4y ago
  This is why user research is so important. I started my career working in UK government applications (GDS), and I'll admit at first I was dismissive of user research as being some kind of hand-wavy nonsense, but I quickly came to believe it is absolutely vital.
- 4y ago
jachee 4y ago
Seems like an attempt at a technical solution to a human problem. My most-frequent swapped-order experience is from couriers running for multiple dispatchers. Rather than getting my order from DoorDash for Jake A, I got one from UberEats which was for Jack H… My name gets read incorrectly as “Jack” all the time, for whatever reason, and I imagine something like that happened with that one. Until/unless it’s economically viable for couriers to run one order at a time, for one dispatcher at a time, these kind of swaps are going to happen.
nneonneo 4y ago
You want the order number to be visually distinguishable from the other information and accessible to an international audience (many restaurants, even in English-speaking countries, are run by non-native speakers and may even cater to non-English-speaking customers!). This rules out using English words for your order numbers. The post suggests using all the letters in the alphabet, but then you run into the problem where once in a while someone will wind up with order #F*CK and complain. So you have to add logic to avoid naughty words, but then you get #FOU in France and realize you need to localize your naughty word list. Or, you could stick with numerals, which everyone understands and which everyone is familiar with (and which are obviously order numbers!). Extending to hex is already a bit of a stretch, but at least there's not that many naughty words using only hex digits.
- TaylorAlexander 4y ago
  Off the top of my head, two letters followed by two numbers seems relatively safe.
  - coredog64 4y ago
    At a previous employer, we used to randomize people’s network logon ID. I don’t recall all the rules, but the big one was removing all the vowels from the set of possible characters. It was robust enough that it worked internationally: US, Malaysia, France, and Czech Republic.
    - vore 4y ago
      Removing all the vowels isn't enough, you can still name someone "FVCK" or "CVNT".
      - Mordisquitos 4y ago
        You just have to treat 'V', 'Y' and 'W' as honorary vowels and remove them as well.
m463 4y ago
Maybe orders should be checked into git and then use the git hash instead...
- raverbashing 4y ago
  Don't give more ideas to the blockchain people...
jhugo 4y ago
The driver currently has to tap something in their Uber Driver app to confirm that they picked up the order. Replace that action with scanning a QR (or other camera-readable) code printed on the receipt. Then even if they pick up the wrong order, they'll find out as soon as they scan it.
- Raed667 4y ago
  I don't believe uber gives the restaurants a receipt printer. They just have a tablet to confirm orders as far as I can tell.
  - jhugo 4y ago
    If they already have one, most are compatible with various kinds of barcode. But perhaps there is an integration problem there. The QR approach I described is how it's usually done here in Asia, and it works well. (I've never had a swapped order, nor heard of it being an issue. Volume is likely considerably higher, too.)
    - Slartie 4y ago
      I work in POS systems, and thus know various kinds of receipt printers rather intimately. It is surprising how much variation the command sets have when it comes to printing barcodes, and especially for more complex ones like QR codes. Older ones don't even support them, you have to resort to software-rendering and printing images instead. And the image-printing commands are just as messy. It would probably be easier to add some kind of OCR functionality into the app to automatically read and parse some kind of textual order ID from a receipt than to ensure that QR code printing works fine on 30 different POS printers from 20 different manufacturers, of which some are over 10 years old. Though a combination would probably be best: print QR codes whenever possible, prefer them when scanning, but when no code is found, try to OCR the receipt and find a textual ID.
      - ilyt 4y ago
        I'd think simple standard 1D barcode would be enough; it's just few letters, no need for QRcode and far more compatible with random label printer
bagels 4y ago
This article doesn't consider that the IDs might not be randomly distributed.
gertrunde 4y ago
I'm faintly reminded of RFC1751 [1] (and the associated RFC1760 [2] that contains the relevant word list), a scheme I still see used in various products to quickly compare crypto fingerprints. (Although including the word "cock" on the word list may not have been the best idea, given how much it opens up the scope for humorous or offensive word sequences - but this was almost 30 years ago). [1] https://www.rfc-editor.org/rfc/rfc1751 https://www.rfc-editor.org/rfc/rfc1751 [2] https://www.rfc-editor.org/rfc/rfc1760 https://www.rfc-editor.org/rfc/rfc1760
fanagra32 4y ago
> If we were talking about 1 restaurant, or even 100, that would mean that 1 in 4,096 orders (or 1 every 40 days) are getting swapped due to this efficiency. Not really. For swapping to occur, two orders have to be sitting there at the same time with the same last 3 digits and the wrong one has to be picked. So thats one in 2x4096. Every time there is only one order sitting there, the propability drops to 0%. And once there are more orders sitting there, it increases beyond one in 2x4096. Where the total ends up is heavily dependent on how often multiple orders are sitting there, waiting. It's hard to quantify, but qualitatively we can certainly conclude that the more busy a place and time is, the more likely this is to occur.
fanagra32 4y ago
> Make the math use bigger numbers. Also, add redundancy so that if something is read out wrong then there is guaranteed to be no match. Error-correcting codes have been around for centuries (well, almost). Simplest way to do this is to add a fourth digit which acts as a checksum. Nobody needs to know this, but it will make the legal combinations very few in the space of total combinations, so if something is read out wrong you'll notice right away.
tbrake 4y ago
The author is perfectly justified in wanting to solve what they see as a problem. However Chesterton's Fence is ever-present in my mind. So I can appreciate the effort behind redesigning/solutioning but my instinct is to try and find out how it got to that place. With 0 insight into what drove Uber Eats design for tickets my wild speculation would be something to do with receipt printer standards (e.g. width/legibility), information density, and restaurant asks - assuming any were polled on what would help them. So it's possible what they arrived at is best or near-best, though imperfect, for their situation. That is, granted, a charitable conclusion but it's reasonable to assume no one there set out to make a bad product. But it's also very possible they got to their first workable state and decided the juice/squeeze ratio of any investment in improvements was nil. "Good enough" strikes in a lot of companies all the time. And, frankly, I agree with other commenters that the swap problem has more to do with imperfections in humans that can't be overcome with better receipts.
- xxuberthrowaway 4y ago
  Was a PM on the team that looked at re-doing the early implementation of restaurant receipts - fun to see this seemingly small but important set of details getting some attention! It was a topic that was discussed in detail and likely still gets examined periodically judging by how the receipts have changed since I was there. Your comment is very accurate. Restaurant POS systems are incredibly limited - some still run on Win2k or proprietary OSes - and not in any way standardized. Field length limits exist all over the place due to seemingly arbitrary manufacturer choices, perhaps due to OS limitations or desire for backward compatibility to even earlier systems. Short fields - as short as possible - scale well. Keeping the shorter codes, which started with the Eats pilot app and largely stayed that way, played nice with POS systems. Likewise for receipt printers - space is at a premium so shorter is better. Defects data are monitored very closely and swapped orders were pretty uncommon overall. Missing item, incorrectly made item or courier not picking up food were far more important problems to solve. Hence your comment 'good enough' was accurate - the system was indeed good enough. Combined with the POS / receipt printer situation and the business case wasn't really there for changing the existing implementation. There is even more inertia to not change things when those changes would impact the kitchens of 10s of thousands of restaurants around the globe, including large ones like McDonald's. The cost of change management in this situation is very real. These restaurants have intricate, in-house produced training manuals and seemingly small changes are a very big deal to them for operational efficiency. Even if the change is better it's still a bunch of doing to execute at global scale. The topic of asks also likely factors in, but in this case probably more from regulators than restaurants. The utensils field is new to me but if I had to guess I'd say likely some regulatory thing but that's just a guess. Could also be a source of defects that has cropped up. Likewise the courier number is a regulatory / security thing - important to both big restaurants and regulators that we're doing everything we can to ensure a secure chain of custody for food even if many restaurants don't use it correctly for this purpose. Naming conventions also receive an unbelievable amount of scrutiny with regulatory considerations in mind. Uber couriers are contractors and Uber was always very careful to structure word choices and operational routines to respect this. Suspect the 'courier powered delivery' word choices are carefully chosen with this in mind and unlikely to be something that would receive the necessary buy-in to change absent a major business impact. To your last correct point - human imperfections in a busy restaurant kitchen are a huge driver of order issues. Kitchens are loud, stressful, busy and increasingly complicated with all the apps. Often the solution to the type of problems seen by the OP was restaurant notification / coaching / reporting / reviews to help tune restaurants into problems that were largely operational even if other tech solutions looked like they could solve the problem. That all being said fun to see a fresh take on what could be possible as well as the code to do it. Appreciate OP taking the time to dig deep into what is a seemingly small product / engineering decision yet quickly becomes a pretty meaty body of work.
ex-uber 4y ago
Ex-Uber software engineer here. Although I only have limited insight into Eats receipt printing, I'll point out a few things the author misses. * Integrating with restaurant point-of-sale systems was an ongoing issue. There is a wide variety of capabilities and APIs. Often with varying degrees of reliability and quality. There's no baseline standard for receipt printers. Regardless a significant percentage of restaurants just do things by hand. It seems to me like the author of this article came to these conclusions with a restaurant sample size of one. * The issue of swapped orders is pretty much exclusively a human one. There's a lot of work ongoing to mitigate this, but receipt code collision is absolutely not related. I would also guess that when an order is generated its code is checked with other ongoing orders. * I like his suggestions to make codes easier to pronounce/hear, but again this is not a common point of failure. He is correct though that when you're operating at Uber's scale, extreme corner case situations happen thousands of times per day.
eliaspro 4y ago
"Throw out C, D, E since they all sound like B, keeping only A, B, F from the first version. Then add in the other visually- and phonetically-distinct letters: H, I, L, M, Q, R, U, W, X, Y." This encodes region-specific assumptions as part of the code logic. This might even differ due to dialects/regional differences in pronouncation and will fail at latest when it comes to completely different languages (for which one doesn't even have to leave the US, given e.g. the huge Spanish speaking community). I don't know whether Uber Eats is available in other countries than the US, but this would bite them in the ass as soon as they're expanding internationally.
raatuter 4y ago
Courier-powered Delivery. That's a lot of big words to mean "someone other than Samuel M will pick this up." Is that what it means? I read it as "the courier will walk or use a bike" eg. not a car. Not that I see how that would be relevant for the reciept either.
xtiansimon 4y ago
“…but at Uber Eats' scale, 10 swaps a day isn't even an hour of a customer support person's time.” In my experience working with platforms for restaurants, any interaction with customer service could take 10 minutes to 45 minutes depending on the problem—security, separation of departments/concerns, investigation of details, approval, resolution.

34 points by fahhem 4y ago

deleted 4y ago

[deleted]

This is conditional on there being 2 simultaneous orders, right? If there's a single pickup per restaurant at any given time, the odds are 0, not .02%.

orlp 4y ago
Yes, but conversely if there's 10 simultaneous orders the probability is 1 - (4095/4096) * (4094/4096) * ... * (4087/4096) = 1.093% to have a collision with a code consisting of 3 hexadecimal characters.

blendergeek 4y ago

Perspective of an Uber Eats Driver: Things may be a bit more complicated than this simplistic blog would suggest. Every restaurant seems to have its own receipt format. Some don't have a name field and uber puts it in the "phone number" field (eg instead of "Name: Arianna" you see "Phone: ARI-IANN-A". Uber has certain information they need to give the restaurant (its different for each one). The receipt has certain fields (these don't match up all the time). It isn't a simple matter of an identifier that can be fixed.

totetsu 4y ago

I feel like the silly factor in reading phrases like 'abstract century' would be a problem if you are reading them or listening to them all day. Like a kind of having abstract poetry foisted on you. Then also take into account the amount of people in the gig-delivery / restaurant business for whom English is not a first language, and may not have matching understandings of letter sound equivalencies, it might be a bit uncomfortable.

blowski 4y ago
It’s similar to what3words and that seems to be working fine.
- arrow7000 4y ago
  Does it? Who uses it?
  - blowski 4y ago
    Quite a lot of the UK police, ambulance, and fire services are using it. I also had a taxi company using it recently.
    - feintruled 4y ago
      It's not without its problems. Mountain Rescue services actively try to discourage its use. https://www.grough.co.uk/magazine/2022/08/31/dont-rely-solely-on-what3words-app-say-lakeland-rescuers-sent-to-wrong-side-of-lake https://www.grough.co.uk/magazine/2022/08/31/dont-rely-solel... This is relevant: https://cybergibbons.com/security-2/why-what3words-is-not-suitable-for-safety-critical-applications/ https://cybergibbons.com/security-2/why-what3words-is-not-su...
- throwaway426079 4y ago
  I can't think of a context where a new w3w is being verbally confirmed every couple of minutes, which is what would happen in a busy restaurant.
  - blowski 4y ago
    Yeah, I don't think the concept works in this case because it's too noisy. But I don't think it's "silly". Everything's silly until it becomes normal.

ZiiS 4y ago

You need to account for the number of simultaneous orders so the maths is wrong. If the is a problem then Uber can just discard order numbers for the same resterant, same day, and same first three digits.

f_allwein 4y ago
That’s what I thought - if you order for pick-up at a restaurant, you get a pickup number consisting of two or three digits. That’s not a problem since there aren’t 100 people waiting to pick up at the same time. So Uber could switch to „Uber Eats 1“ etc, right?

Kwpolska 4y ago

"abstract century" is a terrible order ID. It doesn't look like an order ID, which can be confusing and will require more training. It's two English words, which might be difficult for non-English speakers (Uber Eats is an international service, and the restaurant staff and the courier might not share a common language). Also, what if the random two words end up being "include cutlery"? A better set of characters and ensuring that two order numbers in the same restaurant are very different would be a much better solution.

londons_explore 4y ago
I had to set initial passwords for ~100 users of a computer system. I chose two random dictionary words for each user. I had ~5 complaints that I had deliberately picked an insulting password for a user. It turns out that two totally random dictionary words is offensive a surprisingly large proportion of the time. Eg. 'tiny boots', 'hairy moustache', 'gray face', etc.
- marzipanWhale 4y ago
  If someone called me 'tiny boots' I'd just assume they were comparing me to Caligula
- londons_explore 4y ago
  the funniest was some bloke who really didn't like people making fun of his orange hair... And the random password was "flaming top".

namaria 4y ago

This is a great example of "code tunnel vision". I see it in a lot of developers. They see a problem in the real world and they think "this could be fixed with this snippet of code". Ignoring all the incredibly complex context of running large scale services in the real world: organizational issues, politics, infrastructure, operations, maintainability, etc etc. "It's so fixable! Here are 150 lines of code that solve the problem! How come it exists?" If only everything could be fixed by a pull request.

islon 4y ago
Every problem is trivial when you don't understand it.
raverbashing 4y ago
True. Also their solution has a lot of minor problems as well Upper case letters are harsh when on a big text, but for the case in point they're perfect And no, nobody will shout "abstract century" in a McD, it doesn't make sense. Some delivery apps show the order no. in big letters on the phone, so it can be shown to an attendant, not sure Uber does that, but of course that doesn't work with your 'smart' solution Maybe this is an exclusive Uber problem, maybe because they focus on drivers picking up more than one order
- namaria 4y ago
  That is precisely the problem. You have hundreds of people solving problems with colliding visions and myriad unforeseen issues that need to be addressed. Compromises emerge. There will always be someone who can't discern that their imagination leaves out great many details thinking that they have superior insight.
mathieuh 4y ago
This is why user research is so important. I started my career working in UK government applications (GDS), and I'll admit at first I was dismissive of user research as being some kind of hand-wavy nonsense, but I quickly came to believe it is absolutely vital.
4y ago

jachee 4y ago

Seems like an attempt at a technical solution to a human problem. My most-frequent swapped-order experience is from couriers running for multiple dispatchers. Rather than getting my order from DoorDash for Jake A, I got one from UberEats which was for Jack H… My name gets read incorrectly as “Jack” all the time, for whatever reason, and I imagine something like that happened with that one. Until/unless it’s economically viable for couriers to run one order at a time, for one dispatcher at a time, these kind of swaps are going to happen.

nneonneo 4y ago

You want the order number to be visually distinguishable from the other information and accessible to an international audience (many restaurants, even in English-speaking countries, are run by non-native speakers and may even cater to non-English-speaking customers!). This rules out using English words for your order numbers. The post suggests using all the letters in the alphabet, but then you run into the problem where once in a while someone will wind up with order #F*CK and complain. So you have to add logic to avoid naughty words, but then you get #FOU in France and realize you need to localize your naughty word list. Or, you could stick with numerals, which everyone understands and which everyone is familiar with (and which are obviously order numbers!). Extending to hex is already a bit of a stretch, but at least there's not that many naughty words using only hex digits.

TaylorAlexander 4y ago
Off the top of my head, two letters followed by two numbers seems relatively safe.
- coredog64 4y ago
  At a previous employer, we used to randomize people’s network logon ID. I don’t recall all the rules, but the big one was removing all the vowels from the set of possible characters. It was robust enough that it worked internationally: US, Malaysia, France, and Czech Republic.
  - vore 4y ago
    Removing all the vowels isn't enough, you can still name someone "FVCK" or "CVNT".
    - Mordisquitos 4y ago
      You just have to treat 'V', 'Y' and 'W' as honorary vowels and remove them as well.

m463 4y ago

Maybe orders should be checked into git and then use the git hash instead...

raverbashing 4y ago
Don't give more ideas to the blockchain people...

jhugo 4y ago

The driver currently has to tap something in their Uber Driver app to confirm that they picked up the order. Replace that action with scanning a QR (or other camera-readable) code printed on the receipt. Then even if they pick up the wrong order, they'll find out as soon as they scan it.

Raed667 4y ago
I don't believe uber gives the restaurants a receipt printer. They just have a tablet to confirm orders as far as I can tell.
- jhugo 4y ago
  If they already have one, most are compatible with various kinds of barcode. But perhaps there is an integration problem there. The QR approach I described is how it's usually done here in Asia, and it works well. (I've never had a swapped order, nor heard of it being an issue. Volume is likely considerably higher, too.)
  - Slartie 4y ago
    I work in POS systems, and thus know various kinds of receipt printers rather intimately. It is surprising how much variation the command sets have when it comes to printing barcodes, and especially for more complex ones like QR codes. Older ones don't even support them, you have to resort to software-rendering and printing images instead. And the image-printing commands are just as messy. It would probably be easier to add some kind of OCR functionality into the app to automatically read and parse some kind of textual order ID from a receipt than to ensure that QR code printing works fine on 30 different POS printers from 20 different manufacturers, of which some are over 10 years old. Though a combination would probably be best: print QR codes whenever possible, prefer them when scanning, but when no code is found, try to OCR the receipt and find a textual ID.
    - ilyt 4y ago
      I'd think simple standard 1D barcode would be enough; it's just few letters, no need for QRcode and far more compatible with random label printer

bagels 4y ago

This article doesn't consider that the IDs might not be randomly distributed.

gertrunde 4y ago

I'm faintly reminded of RFC1751 [1] (and the associated RFC1760 [2] that contains the relevant word list), a scheme I still see used in various products to quickly compare crypto fingerprints. (Although including the word "cock" on the word list may not have been the best idea, given how much it opens up the scope for humorous or offensive word sequences - but this was almost 30 years ago). [1] https://www.rfc-editor.org/rfc/rfc1751 https://www.rfc-editor.org/rfc/rfc1751 [2] https://www.rfc-editor.org/rfc/rfc1760 https://www.rfc-editor.org/rfc/rfc1760

fanagra32 4y ago

> If we were talking about 1 restaurant, or even 100, that would mean that 1 in 4,096 orders (or 1 every 40 days) are getting swapped due to this efficiency. Not really. For swapping to occur, two orders have to be sitting there at the same time with the same last 3 digits and the wrong one has to be picked. So thats one in 2x4096. Every time there is only one order sitting there, the propability drops to 0%. And once there are more orders sitting there, it increases beyond one in 2x4096. Where the total ends up is heavily dependent on how often multiple orders are sitting there, waiting. It's hard to quantify, but qualitatively we can certainly conclude that the more busy a place and time is, the more likely this is to occur.

fanagra32 4y ago

> Make the math use bigger numbers. Also, add redundancy so that if something is read out wrong then there is guaranteed to be no match. Error-correcting codes have been around for centuries (well, almost). Simplest way to do this is to add a fourth digit which acts as a checksum. Nobody needs to know this, but it will make the legal combinations very few in the space of total combinations, so if something is read out wrong you'll notice right away.

tbrake 4y ago

The author is perfectly justified in wanting to solve what they see as a problem. However Chesterton's Fence is ever-present in my mind. So I can appreciate the effort behind redesigning/solutioning but my instinct is to try and find out how it got to that place. With 0 insight into what drove Uber Eats design for tickets my wild speculation would be something to do with receipt printer standards (e.g. width/legibility), information density, and restaurant asks - assuming any were polled on what would help them. So it's possible what they arrived at is best or near-best, though imperfect, for their situation. That is, granted, a charitable conclusion but it's reasonable to assume no one there set out to make a bad product. But it's also very possible they got to their first workable state and decided the juice/squeeze ratio of any investment in improvements was nil. "Good enough" strikes in a lot of companies all the time. And, frankly, I agree with other commenters that the swap problem has more to do with imperfections in humans that can't be overcome with better receipts.

xxuberthrowaway 4y ago
Was a PM on the team that looked at re-doing the early implementation of restaurant receipts - fun to see this seemingly small but important set of details getting some attention! It was a topic that was discussed in detail and likely still gets examined periodically judging by how the receipts have changed since I was there. Your comment is very accurate. Restaurant POS systems are incredibly limited - some still run on Win2k or proprietary OSes - and not in any way standardized. Field length limits exist all over the place due to seemingly arbitrary manufacturer choices, perhaps due to OS limitations or desire for backward compatibility to even earlier systems. Short fields - as short as possible - scale well. Keeping the shorter codes, which started with the Eats pilot app and largely stayed that way, played nice with POS systems. Likewise for receipt printers - space is at a premium so shorter is better. Defects data are monitored very closely and swapped orders were pretty uncommon overall. Missing item, incorrectly made item or courier not picking up food were far more important problems to solve. Hence your comment 'good enough' was accurate - the system was indeed good enough. Combined with the POS / receipt printer situation and the business case wasn't really there for changing the existing implementation. There is even more inertia to not change things when those changes would impact the kitchens of 10s of thousands of restaurants around the globe, including large ones like McDonald's. The cost of change management in this situation is very real. These restaurants have intricate, in-house produced training manuals and seemingly small changes are a very big deal to them for operational efficiency. Even if the change is better it's still a bunch of doing to execute at global scale. The topic of asks also likely factors in, but in this case probably more from regulators than restaurants. The utensils field is new to me but if I had to guess I'd say likely some regulatory thing but that's just a guess. Could also be a source of defects that has cropped up. Likewise the courier number is a regulatory / security thing - important to both big restaurants and regulators that we're doing everything we can to ensure a secure chain of custody for food even if many restaurants don't use it correctly for this purpose. Naming conventions also receive an unbelievable amount of scrutiny with regulatory considerations in mind. Uber couriers are contractors and Uber was always very careful to structure word choices and operational routines to respect this. Suspect the 'courier powered delivery' word choices are carefully chosen with this in mind and unlikely to be something that would receive the necessary buy-in to change absent a major business impact. To your last correct point - human imperfections in a busy restaurant kitchen are a huge driver of order issues. Kitchens are loud, stressful, busy and increasingly complicated with all the apps. Often the solution to the type of problems seen by the OP was restaurant notification / coaching / reporting / reviews to help tune restaurants into problems that were largely operational even if other tech solutions looked like they could solve the problem. That all being said fun to see a fresh take on what could be possible as well as the code to do it. Appreciate OP taking the time to dig deep into what is a seemingly small product / engineering decision yet quickly becomes a pretty meaty body of work.

ex-uber 4y ago

Ex-Uber software engineer here. Although I only have limited insight into Eats receipt printing, I'll point out a few things the author misses. * Integrating with restaurant point-of-sale systems was an ongoing issue. There is a wide variety of capabilities and APIs. Often with varying degrees of reliability and quality. There's no baseline standard for receipt printers. Regardless a significant percentage of restaurants just do things by hand. It seems to me like the author of this article came to these conclusions with a restaurant sample size of one. * The issue of swapped orders is pretty much exclusively a human one. There's a lot of work ongoing to mitigate this, but receipt code collision is absolutely not related. I would also guess that when an order is generated its code is checked with other ongoing orders. * I like his suggestions to make codes easier to pronounce/hear, but again this is not a common point of failure. He is correct though that when you're operating at Uber's scale, extreme corner case situations happen thousands of times per day.

eliaspro 4y ago

"Throw out C, D, E since they all sound like B, keeping only A, B, F from the first version. Then add in the other visually- and phonetically-distinct letters: H, I, L, M, Q, R, U, W, X, Y." This encodes region-specific assumptions as part of the code logic. This might even differ due to dialects/regional differences in pronouncation and will fail at latest when it comes to completely different languages (for which one doesn't even have to leave the US, given e.g. the huge Spanish speaking community). I don't know whether Uber Eats is available in other countries than the US, but this would bite them in the ass as soon as they're expanding internationally.

raatuter 4y ago

Courier-powered Delivery. That's a lot of big words to mean "someone other than Samuel M will pick this up." Is that what it means? I read it as "the courier will walk or use a bike" eg. not a car. Not that I see how that would be relevant for the reciept either.

xtiansimon 4y ago

“…but at Uber Eats' scale, 10 swaps a day isn't even an hour of a customer support person's time.” In my experience working with platforms for restaurants, any interaction with customer service could take 10 minutes to 45 minutes depending on the problem—security, separation of departments/concerns, investigation of details, approval, resolution.