Striving for simplicity doesn’t resonate with me. Removing complexity does.
I don’t think either is the “wrong” approach, but in some ways my brain has always approached problems bottom-up rather than top-down.
For example, I start with the code in a new codebase. Architecture diagrams don’t really make sense until after I’ve seen implementation.
I’ve worked with folks, though, who want a thorough overview first before they start filling in any details.
Neither code nor architecture by themselves are sufficient to understand a system enough to change it. Everyone needs both to some degree.
The difference between top-down and bottom-up is just emphasis. I think the same is true when we’re talking about simplicity & complexity.
Bottom-up with a codebase means you prefer to see code first to get a sense of its organization, then compare to architecture diagrams. Top-down means you prefer to see architecture sketched out first, then compare to what the code says.
Removing complexity vs. striving for simplicity feels like a similar pair. "Striving for simplicity" to me emphasizes to outcome (top-level understanding) instead of the process (bottom-up understanding).
I did a whole talk, once, about how the SOLID principles are a beautiful vision of what your code could be like, but gives you zero guidance on how to get it there from where you are now.
The SOLID principles seem useful for a lot of people - perhaps the folks who are more top-down, and for whom "striving for simplicity" resonates.
Where I often have a hard time in this discussion is when the "striving for simplicity" folks phrase it as though anyone who writes overly complex code is less smart, or less experienced, or less valuable.
It's a sore point for me, because after 20 years, I still write a lot of bad code. It's part of my process - I have to write the straightforward, ugly, working thing to fully understand the problem.
In other words - I understand the problem through manipulating the details. Once I get to that point, I can start removing the complexity.
I'm glad there are folks who, as they gained experience, got better at designing things to be simple, and then just implementing them. My brain doesn't really work that way, so I want those folks on my team to complement my approach.
But do be aware that's that's not the only way "smart" or "senior" people do things. There is more than one pathway to knowledge, and each one offers a team different benefits.
For example: perhaps because of my "write working but bad code first, then make it better" process, I'm really good at removing complexity from existing systems. I'm great in a legacy codebase, where other people get frustrated.
The flip side of that is that I get frustrated when given a blank page and asked to design a system that does [x]. Evolution is more my thing than full-on creation.
I find it super valuable to have more creation-oriented folks on my team though, because sometimes it breaks me out of a cycle of evolving something that should just be thrown away.
