|
Top-level
 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. 10 comments
 @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 |
Gregory's Server
*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?