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%.
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.
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.
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.
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?
"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.
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.
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
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.
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.
Additionally having a narrow viewpoint of a situation (at a restaurant, eyeballing some receipts) and assuming you've seen enough to identify the root cause of a problem. There's a pretty large assumption that the cause was mishearing or misreading the order identifiers. They had apparently personally experienced a "swap" twice, but made no mention of whether in these cases this was the cause.
However I don't want to dump on the guy, he broke down what he thought was the problem, and attempted a solution and did so with a bit of humility ("I hope it's clear that I don't think I'm smarter than anyone at Uber, Uber Eats, or really anywhere").
Supposedly Uber has Product Managers and other people considering the user experience. Or do developers choose what to work on directly? I am not familiar with the culture there.
I have to wonder if those codes don't reset every day and if there isn't just another digit added as necessary. The author seems sure they aren't unique?
Even if they weren't unique what are the odds the same restaurant had the duplicate at the overlapping pickup time..
It's a human nature problem, and here's a pretty trivial example in a different realm:
I am a commissioner on the Parks and Rec commission for my suburb (the citizen oversight commission appointed by the city council). I often hear from my fellow residents about some problem that they want solved, and half the people who tell me about problems follow up their problem description with some form of "And if they city would only do X..."
Every time one of these issues is brought before the commission, the staff explain the 37 different factors that they have take into consideration in finding a solution. "Just doing X" is rarely feasible because of a plethora of factors that they person who suggested that was unaware of.
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.
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.
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.
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.
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.)
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.
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).
> 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.
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.
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.
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 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.
"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.
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.
“…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.
50 comments
[ 6.0 ms ] story [ 48.9 ms ] threadThings 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.
https://www.grough.co.uk/magazine/2022/08/31/dont-rely-solel...
This is relevant: https://cybergibbons.com/security-2/why-what3words-is-not-su...
A better set of characters and ensuring that two order numbers in the same restaurant are very different would be a much better solution.
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.
"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.
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
There will always be someone who can't discern that their imagination leaves out great many details thinking that they have superior insight.
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.
However I don't want to dump on the guy, he broke down what he thought was the problem, and attempted a solution and did so with a bit of humility ("I hope it's clear that I don't think I'm smarter than anyone at Uber, Uber Eats, or really anywhere").
Like "fixing" a problem they don't understand.
I have to wonder if those codes don't reset every day and if there isn't just another digit added as necessary. The author seems sure they aren't unique?
Even if they weren't unique what are the odds the same restaurant had the duplicate at the overlapping pickup time..
I am a commissioner on the Parks and Rec commission for my suburb (the citizen oversight commission appointed by the city council). I often hear from my fellow residents about some problem that they want solved, and half the people who tell me about problems follow up their problem description with some form of "And if they city would only do X..."
Every time one of these issues is brought before the commission, the staff explain the 37 different factors that they have take into consideration in finding a solution. "Just doing X" is rarely feasible because of a plethora of factors that they person who suggested that was unaware of.
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.
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.
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.
(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
[2] https://www.rfc-editor.org/rfc/rfc1760
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.
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.
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.
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.
* 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.
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.
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.
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.