4 ms·

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 th

by 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.

by tbrake 4y ago

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.