I appreciate this sentiment, but I think it’s too...simplistic.
I’ve seen a lot of overcomplicated messes. I understand the urge to tell people to simplify.
I think of good engineering as something different than this though. Maybe it starts with how I think about the “complexity” you start with.
”Complexity” to me means a large, multidimensional problem space with many possible solutions, and no obvious optimal one.
The dimensions of the problem are all the things you could optimize your solution for - runtime speed, development speed, uncertainty, etc.
A large part of good engineering is knowing what those dimensions are & which ones you want to optimize in your particular situation.
When people say “make it simple,” they mean reduce the dimensions you care about, so that an optimal solution is obvious.
An overcomplicated mess means the author was trying to optimize too many things at once, for the situation.
But reduced dimensions are not a universal good. You have to reduce it to the _right ones_. And those are situation-dependent.
For example, if you optimize your solution for maintainability, unless you’re careful, you will also make onboarding more difficult.
That makes sense in some situations (BigCo that can spend a long time onboarding) & not so much in others (startup with high turnover).
But the real problem here is that simplicity is just another dimension. It makes sense to optimize it in some situations, but not in others.
A statement like “take complexity & make it simple” basically means “always optimize for simplicity.”
And that’s just as wrong as always optimizing for runtime speed, or always optimizing for developer happiness.
It may be true that good solutions often skew toward that dimension, but the real story is much richer and more interesting than “always.”
And I don’t appreciate the implication in the original quote that folks who don’t optimize for simplicity are being lazy or are unskilled.
I don’t think there is such a thing as essential and accidental complexity (cf Brooks). That is a meaningless distinction.
What appears to be “accidental” complexity is just the visible manifestation of the creators optimizing for the wrong set of dimensions.
The complexity itself can’t be addressed without first aligning on dimensions.
Most technical arguments could be avoided if we just stepped up a level and asked each other, what are we trying to optimize for here?
Side note: refactoring is often just bringing the code in line with current dimensions of interest.
Anyway. We have many technical solutions to complexity - make methods smaller, dependency injection, functional programming, etc.
They’re all just systems that exert design pressure, so that a team _not_ aligned on priorities can end up with code they can all work with.
They sometimes accidentally work. But they fail a lot - that is, a team introduces them but complexity reappears elsewhere.
See also: let’s rewrite this as services!
They all fail, because to succeed in removing perceived “accidental” complexity, a team needs to align on dimensions.
Most people, including me, are not great at articulating what they’re optimizing for.
For example: for a long time, memory space was the most precious resource to conserve in programs. It made sense to manage it yourself.
Java, in the 90s, was the first mainstream language to feature a virtual machine that managed memory for you.
When it came out, a lot of people scoffed and said, it’ll never be more than a toy. You could never run that in production.
Those folks were optimizing for memory space. Java was optimizing instead for developer time. But that wasn’t how people argued about it.
Instead it was “you can’t be a real developer if you don’t write C” vs. “you folks are dinosaurs who can’t keep up with Progress™️”
Another example of “we are bad at articulating what we’re optimizing for”: the readme of basically any open source library.
The readme usually lists features, but almost never says what the creators were optimizing for that resulted in that feature set.
Angular is optimized for java & .net developers who didn’t have time (or perhaps desire) to learn native JavaScript idioms.
But you will not find a single piece of their documentation that says that. I’m not sure they’d even agree. It was likely unconscious.
Aligning on what you’re optimizing for, at the right levels of abstraction, is one of the hardest things for a team to do.
But the times I’ve managed it, really amazing things happened.
Arguments get less personal. They’re about whether it optimizes for the right thing, in the right way. You argue methods, not motivations.
Code gets more uniform, without requiring sophisticated linting rules. Semantics start aligning - not just syntax.
Hiring is easier - say what you optimize for, and “culture fit” just becomes whether they can align with that.
I’ve been workshopping ways to get this team-level alignment faster. I don’t think there’s an easy answer.
This is, after all, one of those multidimensional problem spaces with no clear optimal path.
Fortunately, we know how to navigate those.💅🏻
Fortunately, we know how to navigate those.💅🏻
