battlingcomplexity

Clif's notes on leadership

Battling Complexity, Again

The blog is back. The tools have changed a lot since 2018. The problem hasn't changed at all.

By Clif Render 4 min read

A few years ago I wrote a blog called Battling Complexity. It covered quality, documentation, vendors, and what enterprise architects actually do all day. Then life got busy, the original site went dark, and the articles that survived ended up on LinkedIn.

A lot has changed for me since then. I wrote those posts as an enterprise architect. Since then I’ve moved into IT leadership. Today I’m Vice President, Information Technology, and I lead IT, information security, and privacy for my company. That’s a different view of the same problem. As an architect, I saw complexity in the designs. Now I see it in the budget, in the risk register, in audit findings, and in the attack surface. Every system I’m responsible for has to be paid for, secured, and accounted for, and every unnecessary one makes all three jobs harder.

If anything, I believe in simplicity more now than I did then. So I’m bringing the blog back.

Here’s why. Since 2018 nearly everything about how we build technology has changed. We went all-in on the cloud. We split monoliths into microservices, and some of us are now merging them back together. Platform engineering became a job title. And now AI writes a growing share of our code. If you had told me in 2018 that I’d review pull requests written by a machine, I’d have asked which vendor was selling it. (Old habits.)

Through all of that, one thing hasn’t changed: complexity is still the thing that kills us.

It doesn’t happen in a dramatic outage or a failed launch. It happens slowly. It’s the integration nobody remembers building. It’s the approval process that takes three times longer than the change. It’s the platform chosen for the conference talk instead of the problem. It’s the service that “only Dave understands,” and Dave left in 2023.

What I believe

I’ll put my cards on the table. These are the ideas that run through everything I’ve written and everything I plan to write:

  1. Complexity is the default. Simplicity takes work. Systems never get simpler on their own. Every reasonable decision adds a little weight, and if nobody pushes back on purpose, it piles up.
  2. The best architecture is the one your team can explain. If you need a 40-slide deck to describe how a request flows through your system, the deck isn’t the problem.
  3. Quality is more than “it works.” Functionality is one dimension out of many. Maintainability, reliability, and security are what you pay for later.
  4. Simple systems are safer systems. You can’t protect what you don’t understand. Every system, integration, and copy of data you don’t need is risk with no upside.
  5. Leaders create complexity faster than engineers do. Every new initiative, team, tool, and reporting line adds to the load. Leaders also have the most power to take things away.
  6. Pragmatism beats purity. Simplicity isn’t a religion. Sometimes the complicated answer is the right one. The goal is complexity you chose on purpose, not complexity you drifted into.

What you’ll find here

I’ve brought back a handful of the original articles, lightly edited, because I think they’ve held up. Vendors still show up with new-car smell and silver bullets. Developers still claim that Agile means no documentation. And most teams still test only one dimension of quality.

There will be new writing too, about what simplicity looks like now: how to budget for complexity, why leaders should get better at subtraction, how to write documentation that people actually read, how architecture stays tied to the business, and what happens when AI makes producing code nearly free while understanding it stays just as expensive.

I’m calling these posts Clif’s notes. If you’re old enough to remember the yellow-and-black study guides, you know the idea: the short version, the parts that matter, and nothing you don’t need. That seems like the right format for a blog about simplicity.

I’ve also put together a reading list of the people who have shaped how I think about this: Rich Hickey, Fred Brooks, Dan McKinley, Martin Fowler, Gregor Hohpe, and others. Most of what I know about simplicity, I learned by reading people who said it better than I could.

If any of this sounds familiar, welcome back. If it’s new to you, welcome. Let’s go make something simpler.