A Simpler Time: Balancing Simplicity and Complexity
summary
Argues that complexity is inevitable and must be managed rather than eliminated, distinguishing essential vs accidental complexity (Fred Brooks) and invoking Tesler’s law about who pays. Shows concrete tradeoffs: OAuth2's four flows put most cost on the server implementer, while microservices shift complexity to system ops (decomposition reduces code cognitive load but increases deployment, discovery and runtime tooling). Uses pagination strategies and SDKs as practical examples of where designers choose who bears the complexity.
AI-written summary · about
chapters (25)
- 0:00Intro
- 3:18What is Complexity?
- 5:17Systems Complexity: Emergence
- 6:09Complex Physical Systems
- 7:40Agent Structure (Holland)
- 8:57Emergent and Adaptive Behaviour
- 10:02Complexity in Design
- 10:54Cognitive Complexity: Norman
- 11:18Cognitive Complexity: Maeda
- 11:58Simple or Complex?
- 13:08Complexity is a Perceived Quality
- 13:23Making interfaces Simpler
- 14:02Where Does Interface Complexity Come From?
- 14:52No Silver Bullet - Essence and Accident in Software Engineering
- 15:45Tesler's Law of the Conservation of complexity
- 17:55Managing OAuth 2.0 Complexity: Who Pays the Price?
- 19:56Managing Complexity: The Monolith
- 21:46Managing Complexity: Microservices boundaries
- 22:56Managing Complexity: Client Applications
- 24:31API Lifecycle at Higher Resolution
- 25:09Inherited Complexity
- 26:53Complexity in API Design: Pagination Strategies
- 29:06API Consumption
- 30:02System Complexity as a Feature
- 30:22Extending the System Boundary
related talks
56mKicking the Complexity Habit
38mSimplicity: The Key to Software Success
48mAccidentally Complex Development
18mAPIs at Scale Through Minimalism in Code and Architecture
44mFalse simplicity of front-end applications
01h 07mHow Simple Is "As Simple As Possible"?
32mTaming Complexity through Automation
33mDecoding Complexity:[...]