Levels of Abstraction: the rules of the game and their exceptions

When you wish to play a game, the first thing you do is to try to grasp its basic rules. The story goes that the four-years old Capablanca learned to play chess by looking at his father playing. I tried that with cricket and I still haven't got a clue. Wrong approach, I guess I am not a natural. Normally, we get some explanation from a player or we read the instructions in the box.

Now, there are very general rules which seem to apply, more ore less loosely, to a lot of games. Things like: you do not try to harm your opponent, e.g. by shooting the tennis or squash ball or football , or rugby ball or... at his face.

Is there any very general rule that applies to conceptual games? I do not mean just Sudoku or Scrabble, I mean conceptual/philosophical games/challenges like Gettier problem or The Tower of Hanoi.

Yes, and I would argue that among the most important, if not the most important is this:

get your level of abstraction (LoA) right.

Most philosophical problems are already difficult enough without messing around with this basic rule. Ditch it, and you have a recipe for endless debates about nothing, "fried hair", as they say in Rome.

Why is this rule so crucial? Because a level of abstraction is like an interface, and does three essential things at once:

1. it tells you what sort of information you can get from the observed system (or problem space, or issues or whatever you wish to talk about more generally), therefore
   
2. it tells you what sort of questions is sensible to ask about it, because
3. it tells you what sort of answers you might ever be able to get in principle.
   

It's a Kantian idea: clarify the conditions of possibility of your modeling, and you will know what it is epistemically achievable and what it is not, but above all why certain kind of questions are just a pure waste of time, if perhaps entertaining at smart parties (e.g. "Am I a brain in a vat?" "Do we live in a matrix-like digital reality?").

Now, I just came across (shame on me) a very nice article (dated 2002, see previous bracketed comment) related to LoA and how/why abstractions always "leak": "The Law of Leaky Abstractions", by Joel Spolsky.
It is an instructive reading, which I strongly recommend.

It explains why, in real life, no set of rules can make sure that no further adaptation of the LoA might be required. Basically, new or unexpected features of the real system (being modeled) can always leak through the model (the modeling description at the LoA at which one is operating). To put it in philosophical term: this is related to the underdetermination of models by data, that is, to the capacity of data to be modeled in various ways, while never singly and uniquely determining the model. Because of such underdetermination, because systems are not closed under LoA modeling but always contain more information than one can ever model, one cannot exclude in principle that the LoA adopted will break down, if pushed too hard.

Rules have may have exceptions or there might be cases in which they should not be respected anyway. Likewise, You need to get your LoA right, but every LoA leaks. So where are we left?

Like many things in life, the answer is a matter of approximation. Metaphorically, a drop leaking from a reservoir as big as a lake is nothing, compared to your kitchen water tap. We have LoAs that are more resilient to leakage than others. And the most resilient of all is called "daily experience".

Skeptical arguments (when they are serious) are there to remind us that, even in daily life, lots of "systemic drops" show the think fabric of our common-sensical world. Even our empirical, most basic LoAs leak. But it becomes an issue for purists. They are called philosophers. The taxi driver won't be worried by his occasional mistake of a good-bye-ing person for a customer. LoAs leak, but some leak more than others, and how much they leak is itself a further issue to be assessed at the right LoAs.

Conclusion: get your LoA right, know that you have adopted one but be flexible, as you may need to fix it.

PS
minutes later: sorry I forgot to mention the issuing discussion available here.