> Unfortunately, if this becomes popular, I suspect it'll merely turn into another useless dogma like SOLID and OOP and whatever other buzzwordy acronym-paradig

> Unfortunately, if this becomes popular, I suspect it'll merely turn into another useless dogma like SOLID and OOP and whatever other buzzwordy acronym-paradigms came before. Yes, but that said, if there’s gonna be a dogma I think this one is pretty good. To me, software engineering is the art of curbing complexity. I can see a couple of missteps: - simplicity can be confused with the appearance of simplicity. Yaml is a great example of this phenomenon. - simplicity is subjective, and should ideally be measured by outsiders. However, as we all know decisions and moat belong mostly to insiders, senior engineers that often want to flex and build moat. There’s a risk of curse of knowledge because you can just say “this is simple to me (and if you don’t get it you’re stupid)” - when more people can understand something, you can get more chefs in the kitchen. This is not a problem with simplicity but can be a problem of governance. - engineers can move visible complexity around to areas of less scrutiny. For instance, if there’s a “rule” that a module should be simple, you can break it into two and say they are each simple (even if they’re coupled and it’s only a cosmetic modularization) - complexity from dependencies, concurrency, memory usage etc can fly under the radar, especially for less experienced/gung ho engineers. To be clear, I still like this new trend, these are just some immediate issues that come to mind.