Yeah there are a lot of definitions out there that are along these lines and they do hollow out my argument.

But why call it "Don't Repeat Yourself" if it actually means something somewhat more subtle than that. I firmly believe many junior developers don't grasp the nuance and based on the comments I'm not the only one who thinks this. So if DRY is widely understood by developers to mean literally "don't repeat yourself" and nothing more, does it really matter how the formal definition phrases it?

In any event, if SPOT / SST and DRY do mean the exact same thing, I like SPOT / SST better because the names encode the essential concepts of the principle.

Unfortunately, words mean things and people will take names to mean what they say.

I think the rule should be "Try not to repeat yourself"

Rules are like alarms they draw our attention to some peculiar condition which gives us pause to think about if it's kosher and if not why not.

The art of programming is finding the fit and exceptions to the rules. It's just, frankly, a lot easier to be dogmatic.

Someone says "never do this" or "always do that" and you can apply those rules with abandon (often leaving a maintenance nightmare in your wake).

There are no rules to programming.

I find it useful to think of it as forces pulling on the design, similar to physical forces acting on an object. There are forces that try to keep individual truths/knowledge and responsibilities in a singular place, there are forces that try to minimize abstractions, coupling, dependencies, and indirections, there are forces that try to maximize coherence and separation of concerns, and so on. It’s an essential part of the job of a software engineer to balance those adequately in the design of the software.

Right. There are also "forces" like management who want the project to be finished yesterday.

Another metaphor I like for programming is Chess. Any line you add to the program constrains its future development, becomes "weight" or "force" that pulls your development into some direction. Sometimes you have to sacrifice features like pawns. Sometimes you may sacrifice security, you may think it is secure enough. The outcome of this game is often a draw, or stalemate. And the same game can continue for years.

I think it's an easier pointer to the concept for people who aren't already familiar with it. It actually came up the other day when I was talking to a junior dev who'd written a benchmark by copy-pasting the entire test harness; they couldn't get their head around my explanations of why centralized responsibility is important (although maybe I was doing a bad job) but once I mentioned DRY the pieces seemed to click into place.

There's nothing wrong with "Don't Repeat Yourself" except if it applies to code rather than knowledge.

Any principle like this that is applied to code is wrong.

And "knowledge" is a far more applicable word than "truth."

Truth implies facts, knowledge implies understanding the meaning and associated course of actions.

This is the second time in as many days that I've read something purporting to go beyond some original. The one yesterday was "we need more than the four types of documentation." All the examples fit into the four types as originally defined.

In HR training, there was even an entire segment on the "Platinum rule" because the Golden rule isn't good enough. Yet anyone who works to understand the Golden rule to any depth knows that it encompasses every "enhancement" the Platinum rule intends without any of the side effects.

What kind of failure is occurring such that definitions don't function any more, I wonder?

Maybe, but SPOT is a more memorable acronym than SPOK (or whatever). It allows you to talk about the “SPOTs” where stuff is defined.

One could also use “SPOTify X” to mean “reducing X to a SPOT”. :)

How about "reduce coupling" in that function, "increase cohesion" in this other function. The DRY principle is intending to get you thinking of coupling and cohesion, which, when gotten backward dramatically increase complexity.

The mechanism to "SPOT that code out, bro!" can be applying varying techniques for reducing coupling, and tightening cohesion. A proper review on a merge request should be making more specific comments about how, not a hand-wave to say "DRY that sucker up."

One final comment: DRY is three characters, therefore obviously more efficient :p