Hacker News Reader

Comment by orf | Hacker News Reader

> Software should have the same sort of checks. It's called "contract programming", the simplest manifestation of which are asserts.

A wrong answer is wrong, but the correct response isn't always to fail. Imagine you added this and that caused 0.01% of orders to fail for 10 days while you debug the issue. Perhaps your assert is only stopping a 1 cent deviation from the correct order total - is it better to prevent 0.01% of orders in their entirety or have the absolute correct order total?

Also a value of $0 is a perfectly valid cost for food - maybe they are using a voucher, or some loyalty points, or something else. The Uber eats integration with McDonalds seems to print an order that costs £0.

View on HN

Detected failures should bounce it to the cashier to ring it up. All the McD's I've been in with a kiosk also have a human cashier to help anyone with problems.

> or something else

Easy to account for it.

BTW, the entire reason for the invention of double entry bookkeeping is to detect errors, not throw up hands and say it can't be done.

> Detected failures should bounce it to the cashier to ring it up

Assuming a minor deviation from the real order cost that ends up being more expensive than swallowing the difference and continuing with the order, and it also increases the number of abandoned orders at peak times.

Either way you’re paying a dollar to save a cent.

Because you don’t know what the true value should be (else you have no bug) it’s very hard to choose the correct course of action. I’d argue that attempting to detect unexpected deviations and adding friction to fast food orders could backfire massively at McDonalds scale

Using sanity checks in software is normal practice, especially in software that calculates critical things. It works.

> I’d argue

I'm sure if you put some effort into thinking about how to make it work, you'll be successful.

> Using sanity checks in software is normal practice, especially in software that calculates critical things. It works.

Literally the whole point, that I've repeated to you 3 times now, is that a single cent is not critical if it means losing the entire order.

This isn't a rockets trajectory or a an MRI scanner, it's a glorified tablet selling high-volume impulse food at a good markup, so stop pretending as if the context doesn't matter when discussing things.

> that I've repeated to you 3 times now

I explained how to deal with that.

BTW, crooks have stolen millions of dollars by adjusting software to shave off a penny here and there. The idea that McDonalds can afford to be unaware of a missing penny in a transaction, when they have billions of those transactions, is wrong.

In accounting software, it's critical to be accurate to the penny. Having the POS software be off by a penny calls into question the entire reliability of the software. Especially when normal accounting controls are not followed and the penny error is not detected.

I once read a story where a prospective engineering hire was given a plant tour at Ford. He noticed an inefficiency that was costing Ford 5 cents per car. He was promptly hired.

Edit:

> rockets trajectory or a an MRI scanner

I've heard the same arguments from people who vigorously insist that it's correct for rockets and scanners for the software to ignore bugs and soldier on. I hope the people who do write that software do not agree with those arguments. I suggest that re-evaluating this merits an investment of your time.

> I once read a story where a prospective engineering hire was given a plant tour at Ford. He noticed an inefficiency that was costing Ford 5 cents per car. He was promptly hired.

This seems implausible at best, unless it was long enough ago that 5 cents was a meaningful amount of money. Ford only sells about 5.5 million vehicles per year, so even an inefficiency which affects every single vehicle would only cost $280,000 / year, which is almost certainly not an amount that justifies a process change across all ford assembly lines.

It's important to keep in mind what the acceptable margin of error is. It's very easy to say "no discrepancies are acceptable," but in sometimes you have a legacy system that mostly works and it's not worth the person-hours to stamp out every inconsistency.

Disregarding the point op was trying to make; the ability to spot the inaccuracy might have had more to do with the hiring decision, than the monetary value of the bug itself.

Reply on news.ycombinator.com