Hacker News new | ask | show | jobs
by alexkon 3319 days ago
Can anyone clarify the baseball analogy about errors? (It’s at 38:00.) I’m a bit confused.
3 comments

When Kay says (paraphrasing) 65% of your errors are overhead, he's talking about the difference between say baseball's batting averages and golf.

A batting average of .333 (you hit one ball for every three throws) is considered very good. But you're missing two out of three. In golf, one wrong swing can ruin you.

The point is, when you're doing new things you should be failing often. If you're not you're playing the wrong game.

(I watch many more Alan Kay videos than I do sports, so I hope I'm describing baseball and golf accurately.)

https://en.wikipedia.org/wiki/List_of_Major_League_Baseball_...

minor nit. 1 hit for every 3 plate appearances, not every 3 throws.
minorer nit: 1 hit for every 3 at bats. plate appearances are the denominator for OBP, not batting average.
Touche, since walks are counted differently. Shows I've only been getting back into baseball recently.
One of the chief innovations of baseball as a game is its barouque ruleset, perhaps bested only by Mornington Crescent.
Alan is saying that in baseball there is a distinction between "failures" and "errors".

In the non-baseball use of the terms, a "failure" would be interpreted as a bad outcome, but in baseball as in research, "failure" is inherent to the game and should not be seen as an embarrassment or a negative outcome. A very good baseball player gets on base only 33% of the time. A very good researcher may fail dozens of times for any eventual success.

Conversely an "error" is when you fail to do something that is technically feasible but you fail to achieve it because of a personal mistake. In baseball an "error" would be an outfielder who misses catching a fly ball. Fly balls are caught 98-99% of the time by professional players, and it's expected that they can catch one anywhere in their area of coverage. A researcher should be able to achieve any outcome which is "technically feasible", such as creating a new software language, creating a new operating system, or creating a new hardware integrated circuit if necessary.

To sum up his statements; Failures in research should be expected, embraced, and motivating. Errors are the real problem, and point to an inability to achieve outcomes which are feasible. And if you are achieving ALL your research goals without any failures then your goals are not big and challenging enough.

A baseball error in fielding is when you drop a fly ball, or miss catching a pass. This happens very rarely, maybe 1-5 times per game (or succeeding ~98.5%).

This is because you're doing something easier, catching a ball. Hitting one though, is very difficult (~20-30% is where most professional players are).

He says the design task is much more difficult, and failure should be seen as overhead for part of the process (i.e. R&D process should be failing often, engineering & delivery process should be succeeding in making software ~98.5% of the time).