Rant: The DRY Principle Is Bad Advice | Hacker News Reader

Rant: The DRY Principle Is Bad Advice

medium.com

6 pointsrotemtam11 comments

DRY is simple and should not be thought too much off.

Don't Repeat Yourself. Too many developers look at this principle with refatoring in mind, a lot more than it should be.

If you have duplicate code, and by duplicate, i mean exact copy, then this principle applies. A 90% duplication is not a copy. It's close, but it's not a copy.

Abstractions often come with a much higher cost than duplication. It's much easier to get your abstractions wrong than it is to keep things stupid and repetitive.

Time is your friend here. Don't ever start abstracing, introduce it slowly and a small bit at a time.

I stopped reading at the point where the article gave an example of the clients of the shared code being given extra responsibilities and claimed that the fact that both clients called the same library function meant that they could not be separately changed to cope with the new responsibilities.

> you can't change one without the other.

That's just nonsense. All the coder has to do is either make the shared code parametric or take a copy of it and hack it until it works (choose the approach that makes the most sense at the time). Alright, now it isn't shared, but so what? You can't always predict with certainty that the clients won't share the code at some distant point in the future any more than you can predict before writing it which bits of code will definitely be candidates for sharing.

The hardest thing about growing up in this field is understanding that every day is a practice of a dealing with competing priorities.

As an example, I'm currently writing my own programming language at the moment for board games. I'm prioritizing shipping a game for my friends and myself to play, and this is forcing to leverage WET a great deal because I do not have the primitives yet to even contend with DRY.

Now, interestingly enough, this has been fortuitous since I have many touch-points which enable specific tweaks influence by game rules. Without WET, I could see myself not making progress or refactoring endlessly.

This is leading me down an interesting path, and I'm finally old enough to appreciate that things are going to be messy and weird.

This seems like terrible advice and a terrible clickbait title.

His conclusion is even this:

> Coming full circle, I must admit, the DRY principle is a pretty important piece of advice after all

So DRY is fine. Just be sure you're deduplicating for the right reasons. Like every other "rule" we have out there for programming, there are caveats and you shouldn't be blindly applying rules.

I hate people like this.

If it got you reading all the way to the end and considering where and when should DRY be applied, what are its origins, and what are its limitations then I guess the title did its job just fine.

No, regardless of the outcomes it's not okay to trick people into reading your article through misrepresenting yourself.

here, a question mark was added to the title to better reflect the contents of the article. https://medium.com/@rotemtam/the-dry-principle-is-bad-advice...

I didn't get to the end because the introductory example was such nonsense.

I skimmed it because I don't like criticizing a piece without reading it at all. It's such a vapid blog post that there was no value in reading it completely. It's just "Don't DRY, except do DRY" with a provocative title. If the title were actually honest about what the post is about, I wouldn't feel so annoyed with the post, but it does and I'm annoyed.

DRY is just a principle. It must be applied in accordance with common sense. As a character of one of Asimov's book used to say, "Never let your sense of morals get in the way of doing what's right".

"Repeat yourself for max 3-5 times" is a much better principle.

Copy & paste is a fundamental principle for reason. Just when it becomes a burden you need to abstract.

Reply on news.ycombinator.com