We've all watched "Simplicity Ain't Easy" and "Simple Made Easy" enough times to do the call-and-response, dictionary-definition slides and all. Personally, I've been deeply shaped by the ideas from Stu, Rich and others in the community. I love simplicity.

And, while simplicity is one of Clojure's great gifts to software, it's not free. Finding the "simples" in a domain takes time, and composing them brings real costs. Sometimes an easy or expedient implementation — the complected, messy thing that works today — is what keeps our product or company alive long enough to improve tomorrow.

Drawing on these evergreen talks and Richard Gabriel's "Worse is Better" essays, this talk asks: when should we decomplect, when should we choose ease, and is that choice even binary? We'll build a set of clues, considerations, and guiding principles to help us read trade-offs and context so we can deliver what we need today without cutting ourselves off from the path to Better.

Aaron Brooks

Aaron has been writing software for over 40 years and Clojure since its early days. He was part of the community before the first Clojure/conj, has given talks at Clojure conferences, and ran a Clojure meetup for more than a decade. He spent over 10 years leading Clojure training, adoption, consulting, and engineering at Viasat, worked at a Clojure startup, and now leads engineering operations at Supabase. The ideas in talks like "Simple Made Easy" and "Simplicity Ain't Easy" reshaped how he thinks about engineering — which is exactly why he wants to look hard at what simplicity costs, and how to apply it well.