Gregory's ServerJust hit publish on a post I've been thinking about writing for years. I know I've had this running through my head for a while now, feels good to write it down. It's about "Complexity"
 22 comments
 s/complex/bad design/ and your blog post would still make sense. Complexity is all about mental simulation. The ability for a single brain to host a simulation of the given system and which interfaces are "simple" and trustworthy enough to have faith in (faith here means, to not have to think about) The reason we want systems designed by multiple people (see my PenPot fest talk) is because... 1/2 @paul ... A single brain can create a complex system that reflects it's inherent structure. It's thus easier for that same brain to *simulate* the complex system later and much harder for other people. A *star* programmer is just someone that got there first with no one else to collaborate with. APIs are just modularisation interfaces between simulation domains. Design is critical, a bad design will require the outside programmer to simulate the inside of the API. A good design will not. @paul @Foxboron I've not -- but you of anyone know how much I like the guy! I'll give it a watch asap ♥️ @Foxboron I'm really bad at actually watching talks if I'm not at somewhere, even if it's legendary 😂 Some of my fav bits from the blog: Is a solution complex because it’s complex for the end user? Is it complex if it’s complex for an API consumer? Is it complex if it’s complex for the person maintaining the API service? Is it complex if it’s complex for someone outside the team maintaining it to understand? [..] There’s a fixed amount of complexity in the problem to be solved, and you can choose to either solve it, or leave it for those downstream of you to solve that problem on their own. *stares into the void* What’s more complex? An app running in an in-house 4u server racked in the office’s telco closet in the back running off the office Verizon line, or an app running four hypervisors deep in an AWS datacenter? Which is more complex to you? What about to your organization? In total? Which is more prone to failure? Which is more secure? Is the complexity good or bad? What type of Complexity can you manage effectively? Which threaten the system? Which threaten your users?  @mhoye I really like your map–territory relation analogy here; definitely resonates with me!  @paul @mhoye I also think about Latour's theorization of "black boxes". he says that complexity becomes black boxed once a mechanism's running becomes a settled "matter of fact". I recommend his "Pandora's Hope" -- it is a wonderful book that asks the question: what happens, in a epistemological and ontological sense, when we abstract away complexity? What are the *mechanics* of that? I agree there's a fixed amount of complexity in the problem to be solved, but there's no upper bounds for the complexity of the solution. In addition to allocating the complexity appropriately when you architect the solution, it's also critical not to take on more than you need to. @scottk oh no problem at all, I figured, totally fine -- definitely hard agree with everything you're saying  @paul Nice write up. The way I look at complexity is around how many moving parts you need to know about to have a useful mental model of the thing you are dealing with. Symmetry and invariants simplify things. E.g. EKS is the same in every AWS region globally, while a hand crafted k8s cluster in every region would be far more complex to understand. When something breaks an invariant or hidden implementation details become important that adds complexity. @paul A common tradeoff is between efficiency and simplicity. Doing it the same way everywhere is much simpler, optimizing everywhere is more efficient but now you have to understand what the local optimization was, which is more complex. |
@paul damn it! I've literally just now written "I like it because it's not too complex" in a review. Have you been sniffing my GitHub sessions?!