
Rant: The DRY Principle Is Bad Advice - rotemtam
https://medium.com/@rotemtam/the-dry-principle-is-bad-advice-78c51afd5cf0
======
danielovichdk
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.

------
kwhitefoot
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.

------
mathgladiator
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.

------
Sevaris
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.

~~~
rotemtam
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.

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

~~~
rotemtam
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...](https://medium.com/@rotemtam/the-dry-principle-is-bad-
advice-78c51afd5cf0?source=friends_link&sk=8f5d77ebee500b15d4427f419f792572)

------
skywal_l
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".

------
rurban
"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.

