[rched]

I don't think you can separate the principle from its misapplication. It's misapplied because it tries to stuff useful knowledge into a memorable phrase and the nuance is lost.

Flagging code in code review is another great example of harmful behaviour principles encourage. I've stopped referencing principles altogether in code review and I encourage others to do the same. Instead I focus on trying to explain the specific impact the code will have on our specific codebase.

[dasil003]

> I don't think you can separate the principle from its misapplication.

In practice you are right, but this is just part of the human condition. There is no substitute for experience. Wisdom can’t be taught. The map is not the territory. Yada yada.

Principles still have value as short-hand for knowledgeable practitioners though. In fact, they have outsize value in this case because strong programmers will recognize and reflect on both the upsides as well as downsides discussed here. Communication bandwidth is the single most important thing to scale teams working on irreducibly complex domains.

[ozim]

I also sign up into thought school where “principles” went bankrupt. When I see someone quoting principle as a sole reason for code change it automatically shouts it is shallow explanation without much thought.

[bcrosby95]

We could adopt a principle to solve this problem: something that reminds us that abstractions aren't free.

This is the source of the problem of the blind application of principles - which tend to increase the number of abstractions. They aren't free, and people act as if they are.

Even good abstractions have a cost. But in a good abstraction, the benefits outweigh the costs.

[ozim]

Looks good for me. I also see that people treat abstraction or indirection as "always good" or at least "free".