[gcassie]

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.

[naniwaduni]

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

[galaxyLogic]

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.

[cogman10]

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.

[layer8]

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.

[galaxyLogic]

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.

[SpicyLemonZest]

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.

[wvenable]

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.