Weekly Reflection #1 - Simplicity, Complexity, and Design

Each week, I share one insight. One piece of wisdom. One question to reflect on. (and a little Lagniappe)

Insight

I’ve never seen a codebase accidentally get simpler. Every “temporary” workaround, every “we’ll refactor later,” every “just one more feature” adds up.

Complications tend to creep in. Slowly. Quietly. It starts small, many times unnoticed. It’s not malicious. It’s entropy. Without deliberate effort, all systems drift toward chaos.

The teams that stay in flow aren’t the ones who never deal with complexity. Complexity emerges over time. They’re the ones who refuse to accept 'it’s complicated' as an answer. Letting complicated creep in is a choice. So is insisting on simplicity.

Wisdom

In 2024, I had the pleasure of interviewing John Ousterhout, author of A Philosophy of Software Design, on the Book Overflow podcast. One of my favorite insights from our conversation was on the importance of iterative design to manage complexity:

“We can’t fully design a system up front - the systems become too complicated, it’s too hard to visualize the consequences of our design decisions at the beginning… But the other extreme of doing no design is even worse. The sweet spot is somewhere in the middle where you spend some time doing design but also recognize you’re not going to get it right, and so you make sure… you better leave time to also go back and do major revisions on things.”

This is why Ousterhout advocates “designing it twice” because you can’t fully get it right the first time. The complexity you’re fighting isn’t a sign of failure. It’s the nature of the work.

Check out the Book Overflow interview here.

Reflection

What is one thing you’re no longer tolerating that you would have tolerated two years ago?

Lagniappe (a little something extra)