One of the most interesting insights I retained from my machine learning course from a couple of decades ago is that you can put a mathematical bound on how qui

One of the most interesting insights I retained from my machine learning course from a couple of decades ago is that you can put a mathematical bound on how quickly you can learn from a given set of data, and how much you can learn. In the situations presented by the real world this is often not very interesting because we can only process such a vanishing fraction of the data available that we're so far below this theoretical optimum that it's uninteresting, but in more constrained situations it can be relevant. In this case, while I agree that there was enough data to have a good guess that something had gone wrong after a certain period of time, it definitely is the sort of noisy data that would take some non-trivial aggregation to be sure, and even in hindsight I'm not so sure the signal was so strong that it's worth metaphorically beating anyone up about. Moreover, only in hindsight is it obvious that the culprit was a doubling of melee damage. Prior to knowing that, the learning rate was constrained by the multiplicity of possible theories that could have explained this. It's not like it was simply a matter of "Either 1. the game is unchanged and people have just Got Gud or 2. the melee damage rate has been doubled", the span of possibilities was much larger than that. Had an oracle come down from whereever and offered that choice to the devs, sure, gathering enough data to resolve that one bit's worth of information would have been easy. But presented with the full, massive array of possibilities, it's a much harder task to even determine that there is a problem, let alone what it is. Upshot, don't beat yourselves up too much. It may be obvious in hindsight but these are really quite hard problems to solve in the deliberate absence of information.