--- title: "Control and complexity: tension in systems design" url: https://daily.dev/posts/control-and-complexity-tension-in-systems-design-pq69wzj8a source_url: https://ferd.ca/control-and-complexity-tension-in-systems-design.html type: article source: "Planet Erlang" published: 2026-08-10T12:34:13.377Z updated: 2026-08-10T12:34:40.798Z tags: ["llm", "architecture"] reading_time: 21 upvotes: 1 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Control and complexity: tension in systems design **[Planet Erlang](https://daily.dev/sources/planeterlang)** · 21 min read · 1 upvotes · 0 comments ## Summary A deep exploration of two contrasting philosophies in systems design: analytical decomposition (control-centric) and complexity/emergence thinking. The post contrasts how each approach handles training, safety, correctness, reliability, incidents, and feature development through comparative tables. It argues that most organizations default to doubling down on control when systems grow complex, often missing the hidden adaptive behaviors practitioners have built. The post offers diagnostic questions for both approaches and warns against uncritical adoption of either, especially as LLMs reshape software workflows. The key insight is that activities like code review, SLOs, and chaos engineering can serve both philosophies, but the underlying stance determines their effectiveness. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is the difference between analytical decomposition and complexity/emergence approaches in systems design? Analytical decomposition assumes a system can be understood by breaking it into parts, predicting behavior, and enforcing control through processes, tests, and hierarchies. Complexity/emergence approaches accept that interconnected systems resist analysis and instead focus on fostering adaptive behavior, small iterative interventions, and understanding interactions rather than imposing structure. Both have distinct implications for reliability, safety, incident response, and feature development. _Engineers navigating LLM-driven workflow changes track these architectural debates on daily.dev._ ### What questions should I ask when designing a control-centric software system to avoid hidden failure modes? A control-centric system should be stress-tested with questions like: Are our observations still surfacing the right signals? Is our understanding of the system losing accuracy over time? Are we suppressing variability that is necessary for adaptation? Are the things we optimize for creating brittleness elsewhere? Is our control real or illusory, and how would we know if that changes? Well-regulated systems can hide accumulating problems at both technical and cultural levels. _Architects building resilient systems find edge-case thinking like this surfaced regularly on daily.dev._ ## Similar posts on daily.dev - [I Thought Working Code Was Good Enough. I Was Wrong.](https://daily.dev/posts/i-thought-working-code-was-good-enough-i-was-wrong--sht2vtiff) · Medium · 0 upvotes · 0 comments - [The Programmer's Paradox](https://daily.dev/posts/the-programmer-s-paradox-0jiktgc9d) · Hacker News · 1 upvotes · 1 comments --- Tags: [#llm](https://daily.dev/tags/llm), [#architecture](https://daily.dev/tags/architecture) [View this post on daily.dev](https://daily.dev/posts/control-and-complexity-tension-in-systems-design-pq69wzj8a)