The other day, I stumbled upon this post from 2019, and a couple of points in it resonated with me:

The Danger of “Simplicity”
There are a few tendencies among programmers that involve the totem of “simplicity.” There’s the ancient concept of KISS, of course, but there’s also the much-abused YAGNI, the insistence that we “Choose Boring Technology,” entire languages that base their elevator pitch around the idea that they’re…
... every decision made in order to simplify a program will cost something.

It's good to think about simplicity in terms of the tradeoffs we make when we take a particular decision. Reducing language features might make the code easier to comprehend but slow down the adding of new functionality. On the other hand, optimizing for developer productivity will inevitably bring the codebase to a point in which a rewrite of some sort is necessary.

Pareto's rule is at play here too. While most programming language choices will satisfy about 80% of the problems out there, there will always be that 20% where one choice is the better fit. You can certainly write your websites in your preferred language of choice because you're much faster that way, or you might use vanilla HTML because it suits the problem domain better.

Either way, it is crucial to understand that success or failure is not a single state of being but a continuing, iterative process. What worked yesterday might become irrelevant tomorrow and be good again in 10 years.

This does not mean that all software must be rewritten every year to fit the latest tech trends. That's both impractical and unfeasible. When Rails came out, it was pronounced to be a "PHP killer," later came other frameworks that, in their turn, were thought to be the "Rails killer." Last I checked, both PHP and RoR still power much of the Internet we know today and are stronger than ever.

Yet, it's good to write software in such a way, in which it is easy to replace one part with another when a better (for the time being) alternative shows up. All of us have our preferred tastes, and that's OK. We can't all be good at everything. Acknowledging this fact and being open to including other opinions will more easily result in "simpler" (more cohesive) code than blindly following any dogmas or stringent code standards.


If everything is a tradeoff, how do we make any decision about the design of our software at all? It’s tempting to make hard and fast rules. There are plenty of those: “Methods should never have more than five lines of code,” “no line of code should be written without a unit test,” or “all production code is pair programmed.” What this is doing, though, is hiding the choice from you (or lying about it). It’s not that the choice wasn’t made, it’s that someone else made it, and now wants to convince you that their opinion has no cost.
Instead of accepting this at face value, instead think about how to make those choices for yourself. Think about the different ways that code can be simple, and the things to which that particular simplicity is opposed.