Deprecating Simplicity 3.0

*Casey regularly rewrites major components of this talk. The Program Committee watched him present again at GOTO CPH 2018 and enthusiastically confirms that it is definitely a completely different talk well worth watching!* When engineering teams take on a new project, they often optimize for performance, availability, or fault tolerance. More experienced teams can optimize for these properties simultaneously. Now add an additional property: feature velocity. Organizations often try to optimize for feature velocity through process improvements and engineering hierarchy, but some optimize for feature velocity through explicit architectural decisions. These decisions increase the complexity of the system. This sounds like a trade-off: you get feature velocity, but for the price of increased complexity. Mental models of architecture can help us understand the tension between these engineering properties. For example, understanding the distinction between accidental complexity and essential complexity can help you decide whether to invest engineering effort into simplifying your stack or expanding the surface area of functional output. Spoiler alert: most businesses prioritize feature velocity over simplification. Chaos Engineering was born within this conflict between feature velocity and increasing complexity. Rather than simplify, Chaos Engineering provides a mechanism for us to embrace the complexity and ride it like a familiar wave, maintaining our business priorities while dialing up feature velocity.