The Path of Madness
Software teams often adopt complex tools like microservices and Kubernetes due to hype, not need. This "path of madness" leads to slower development and burnout. The author advocates for simpler, pragmatic solutions matched to actual problem scope.
Background
- Brandur Leong is a well-known senior engineer (formerly at Heroku, Stripe, and others) who writes the respected engineering newsletter "Nanoglyphs."
- "The Path of Madness" is a recurring theme in Brandur's writing, referring to the misguided belief that production incidents can be eliminated entirely through ever-more-complex automation and process—an approach that instead leads to burnout and brittle systems.
- The post argues that mature engineering organizations accept a baseline level of failure ("normal accidents") and focus on fast recovery and resilient design rather than chasing 100% uptime through heroic measures.
- This piece is part of a longer tradition in operational thinking: Richard Cook's "How Complex Systems Fail" and John Allspaw's work on resilience engineering, which Brandur often references.
- Key concepts include: error budgets (from Google's SRE model), the difference between safety-I (preventing failures) and safety-II (ensuring things go right), and the danger of "normalization of deviance" in high-stakes systems.