Yes. But more importantly, we are continuously training our network. There is no terminating "training set" except the set of all considered classifications. Our discovery of ourselves being "wrong" about a thing is our network continually adjusting. We also have the notion of ignorance. These classifiers are often forced to come to a conclusion, instead of having "I don't know, let me look at it from another angle" kind of self-adjustment process. "Aha, it is a cat!" moments do not happen for ai. In us, it would create a whole new layer to wrap the classifier around some uncertainty logic. We would be motivated to examine the reasons behind our initial failure, and use the conclusions to train this new layer, further developing strategies to adapt to those inputs.
reservation bailing, like scalping can be solved through new business models: for reservation fraud, start by taking a creditcard and charge a 5$ reservation fee that is deducted from your bill. For scalping, there are a lot of various approaches that work.
Saying that "It's easy to solve, so if the restaurants haven't yet, it's probably not a problem" is pretty bad as excuses go.
The point isn't that it can't be solved, the point is that if it need solving, it's probably a problem, and companies are supposed to solve problem, not to deport them from their paying customers to non-paying third-party.
It is very difficult for me to translate lessons learned at google to anything except google. I have read a lot of blogs from googlers and formers who write from a perspective of, I guess, a luxury I have literally never seen, even at MS during its golden age. For example, the idea of code reviews and whitespace. I have never worked in an environment where we had that kind of money to spend.
" code reviews and whitespace. I have never worked in an environment where we had that kind of money to spend."
Also my experience with google coding practices. Code reviews process can be excruciatingly long and painful (especially when you're starting out). Lots of back and forth over things like whitespace between operator/operand and whether to put the stream operator at the end of a continuing line or at the beginning of the continued line etc.
Someone else said that the google practices are optimized for code maintainability rather than developer efficiency. Absolutely true. Reading code (at least C++ which I have experience with) at google is a joy while writing (and submitting) code is at best a chore. At it's worst it's bad enough that I've seen a new hire (senior engineer, known for delivering at a high level from his previous company) go back to his old company after a quarter or so of frustrations with the process.
