Complexity Used to Impress Me

Earlier in my career, complexity impressed me. Big architectures, lots of services, clever abstractions, systems that needed a diagram just to explain how the pieces fit together. They felt sophisticated. I’m much more suspicious of it now.

I went back recently to Werner Vogels’ keynote at AWS re:Invent 2024, which he built around a word he called “simplexity.” I spoke at re:Invent back in 2017, when we were moving Encirca out of its data center, and I’ve watched a lot of these keynotes since. This one has held up better than most.

Complexity doesn’t go away

His starting point was Tesler’s law: complexity can neither be created nor destroyed, it can only move somewhere else. (It’s close to what I was getting at in Scarcity Doesn’t Disappear. It Moves., just about systems instead of priorities.) That isn’t a reason to give up on simplicity. It’s a reason to decide where the complexity lives.

He split it into two kinds. Intended complexity is what you take on deliberately, because the system has to scale or do something genuinely hard. Unintended complexity sneaks in while nobody’s paying attention, and that’s the kind that eventually sends you a bill. His warning signs were familiar enough to be uncomfortable: feature velocity slowing down, frequent escalations, debugging that takes forever, dependencies everywhere. The one that stuck with me was the plainest. A service has gotten too complex when the engineers who own it can no longer fully understand it.

That’s the cost the architecture diagram never shows. Every component you add has to be understood, deployed, monitored, secured, upgraded, and eventually replaced. Adding another service might take a day. Living with it can last ten years, and someone has to trace a request through five different systems when it breaks at 2 a.m.

Scale isn’t the same as complicated

Vogels was clear that some complexity is the price of doing hard things. S3 took on real complexity to support its scale and its move to strong consistency. He also told the story of CloudWatch growing into a “mega service” that had to be broken back into smaller pieces with clear APIs.

That second story is the one I recognize from large organizations. We build frameworks for every possible use case, add layers because different teams own different parts of the stack, and build generic platforms before we know whether we have a generic problem. Eventually a fairly straightforward problem takes three teams and six pieces of infrastructure, and we call it enterprise architecture.

The best counterexample I’ve seen came from an engineer on a team I worked with. He was asked to build a system that could quickly find and analyze huge numbers of high-resolution, multi-band rasters and produce a pivot of the data. That’s a genuinely hard problem, and he got the implementation down to something so simple that people who dig into it are still surprised by how little is there. He’d done the work of deciding what didn’t need to exist.

Simplicity is hard

That was more or less where Vogels landed, and it’s the part I agree with most. At Granular, simplicity was one of our core values: reach for the simple approach before the complex one, and keep pushing to simplify complicated requirements and engineering instead of just accepting them. Written down, that sounds obvious. Living up to it takes judgment, because you have to understand a problem well enough to tell which complexity is real and which you introduced yourself.

Most of his six lessons, like making evolvability a requirement and aligning teams with the architecture, are really about keeping the intended kind from quietly turning into the other kind.

AI makes this easier to get wrong

The talk is from late 2024, and it reads as even more relevant now. It has never been easier to create another service, another abstraction, another thousand lines of code, and an agent will happily build all of it. None of that means it needed to exist. If Tesler is right and complexity only moves, cheap code mostly moves it somewhere you’ll pay for later.

I still like sophisticated systems, and some problems deserve them. What gets my attention these days is something that solves a hard problem and still feels obvious when you look at it.