Thinking about extremes

(Sometimes I make notes when reading books with the intention of compiling them into blog posts once I’m done reading. So far I have failed to do this because it becomes a big task at the end of the book, so I’m trying to do better by publishing notes as soon as I have something meaningful instead.)

I’m reading The Socratic Method: A Practitioner’s Handbook, based on a recommendation by Rich Hickey on his talk Design in Practice.

At some point the book mentions the elenchus, a method used by Socrates to test the consistency of a claim or argument by finding another claim that is also agreed to be true, but ends up contradicting the first claim.

The book briefly mentions that you can use the elenchus to test your own beliefs to the extremes, but doesn’t go further into this. I don’t know whether the book will eventually discuss this in more depth, but here’s a note on “testing beliefs to the extremes”:

Whenever thinking about a subject or argument, I found it to be very useful to push the subject or argument to each of its extremes. This allows you to identify the “bounds” of the space you’re thinking about, helps you situate your own belief about the subject in this space, and most of all helps avoid duality¹ in your thoughts.

An example which is unfortunately technical because I can’t think of a better one right now: imagine you want to build a system of computers to do some work you find useful. However, the solution you thought about will require some coordination between the machines, which is proving to be an obstacle to implementing the solution.

The first step is important, which is to recognise that the issue is about coordination rather than “which database do we use that will scale to multiple machines connecting to it”, or whatever other problem comes from your particular solution for the system. This method doesn’t help with the first step, and at some point I hope to write about methods to identify this first step. I apologise if this feels like “draw the rest of the fucking owl” to you.

After the first step, this method can be applied to let you explore the space of solutions, and maybe even come up with a better solution. Say you don’t want any coordination to happen between the computers (you’ll need to force this property). How does a system like this work? By forcing the “no coordination” rule and thinking about it, you’ll start to solve that puzzle and come up with ideas. Perhaps load balancing comes up into the solution, and it will obviously have its drawbacks, and from there you start to think about ways you can make it work better².

Similarly, you think about another extreme: let’s force a single source of truth, and say that a single computer will be responsible for coordinating work among other computers. How does a system like this work? As you think about it, you’ll find drawbacks for this solution as well (if the coordinator machine stops working, the system will stop until a new coordinator exists), and think about solutions for those drawbacks.

It is natural that as you think about the implications of each extreme, you’ll be pulled towards the other end to solve the drawbacks. This is one of the benefits of doing this exercise: you’ll gain a better understanding of where each smaller solution fits within the space of solutions, and why it is useful. The implication of this is that you’ll be able to situate your own solution into this space, and might be surprised at how easier it is to explore alternative solutions which end up stronger than the one you started with.

You can obviously do this for things that don’t have only 2 extremes as well. It becomes a bit harder to think about, at which point I’d suggest you go watch the Rich Hickey talk I mentioned in the beginning of this post :)