
Write Everything Twice - lifeisstillgood
https://dev.to/wuz/stop-trying-to-be-so-dry-instead-write-everything-twice-wet-5g33
======
wpietri
This is good advice, but I'm a little disappointed to see it written up as a
complete novelty. The principle appeared in Martin Fowler's 1999 book
_Refactoring_ as the "rule of three", where he attributes it to programmer Don
Roberts. I've heard it a zillion times in discussions about when and how to
refactor.

~~~
Rapzid
I have my own rule of three that I also try to apply to use cases for adding
functionality in a way that's not overly specific. Never heard of it before.

But now that you mention it, I haven't _actually_ read Refactoring :| The
knowledge actually required for programming is tiny compared to what's
available; people's exposure is all over the map.

------
moron4hire
This one seems to be this generation of newly minted senior devs' hot button
issue.

Dogma in general is anethema to innovation, but that doesn't mean particular
practices are wrong just because some people are dogmatic about them.

------
thisiszilff
The broader concept here is that "people can tolerate a little bit of smell."
Code smell is bad, but it also tells you what needs fixing and where your
design is lacking. As a principle, I like to operate under the assumption that
hacks and nonstandard code is ok IF they can be explained and kept in mind by
someone coming into the project. Usually that means a 3 or 4 warts can pop up
before I begin to refactor and remove them.

------
a8b
Live in the spirit of the law not the letter of the law. I never took DRY as
an excuse for premature optimization or to it's logical extremity in practice.
To me applying WET principles would be indistinguishable from DRY in practice.
I think it's better to understand that than to redefine the law.

------
martin_drapeau
Its always nice to see a developer realize this concept on their own. Self
discovery is a sign of acquiring experience and a great thing. Don't mind the
others putting you down because you didn't reference the rule of three.

I like the WET acronym counterbalancing DRY. Nice touch.

------
dkrikun
This is a good advice, but I feel to add a few points of mine:

1\. the author says "premature optmization", and it has the right context,
however I prefer to use "premature abstraction" or even "speculative
generalization".

2\. YAGNI and DRY can be counter-principles because at times "you aint gonna
need that level of abstraction/genericity".

3\. Inadequately abstract and generic code hurts simplicity and readability.

------
michaelcampbell
While this blog post is new, I've heard this acronym used in this context for
at least a couple years.

------
Martindm
Not sure I'm on board with the premise if the article. Author presents
duplication of HTML elements as a commonplace exception to DRY; This is not
what DRY is.

Can't agree to overturn a tried and true best practice, in favour of the
opposite, as the article suggests. While easy to play around and adhere to the
dogma of DRY at all costs; namely making code difficult to reason and taking
ages to do it; we just call this premature optimisation - DRY done with no
critical thought about priorities.

Tldr; don't optimise for DRY too early or at the cost of what's most important
or expedient. Use common sense and adopt DRY only as far as necessary for your
team and to help others extend and be efficient working with your code. Not a
bad article but maybe just complicating what we already have a name for.

