The “don’t repeat yourself” principle is well established, but over-aggressive refactorizarions to extract common code are also widely known for creating hard to maintain code due to the introduction of tight coupling between components that should not be coupled. A passing resemblance between code blocks is reason enough to extract them away, even if that ends up breaking Liskov’s substitution principle.
To mitigate problems caused by DRY fundamentalisms, the “write everything twice” (WET) principle was coined. WET works by postponing aggressive refactorizarions, the kind that introduces complexity and couples unrelated code just because it bears some resemblance, by creating a rule of thumb where similar code blocks showing up twice in the code should not be refactored, and only code that shows up multiple times should be considered for this task. However, this rule ignores context and nuances, and can dissuade developers from cleaning up code.
So, where do you stand on the topic? How do you deal with duplicate code? Do you follow any specific rule of thumb?
WET is not what you think it is, or at least not originally. It’s not some alternative to DRY. It didn’t stand for Write Everything Twice. It stands for Write Every Time. It’s supposed to be a negative way to describe code that isn’t DRY. It’s also abbreviated as “Waste Everyone’s Time”.
Much, much, much later somebody tried to reuse the term for “Write Everything Twice” but talking specifically about the benefits of singular, repeated templating because the abstraction needed to refactor code into “Write-Once” can make things harder to understand. In other words, it creates a chain of pre-required knowledge of how the abstraction works well before you can even work with it.
The irony here is that DRY is not really about code duplication. It’s actually about system knowledge (structures and processes) being clear and unambiguous. Or, applied, you, as a person, not having to repeat yourself when it comes to sharing knowledge. It lends to simpler constructs that don’t need much explanation. The example given of Write Everything Twice is actually being DRY, but they don’t realize it.
https://www.artima.com/articles/orthogonality-and-the-dry-principle
The article/interview explains more about how DRY is meant to work and even talks about the pitfalls of code generators, which the WET article complains about (React).
The misunderstanding since DRY’s coining is probably because, like natural language, we change meanings we with our environment. DRY became a term people use to blast too much abstraction. But noisy abstractions are not DRY. In response we have a new term card AHA (Avoid Hasty Abstractions), which exists as a counter to what people think DRY is.
The TL;DR is DRY is meant to mean your code should be unambiguous, not some sort of mantra to deduplify your code. Apply its original principles, and follow AHA which should be a clearer safeguard to avoid your abstractions not following DRY.
I think you’re confusing things. Write Everything Twice (WET) has no resemblance with the concept you mentioned, which makes no sense to be a standalone concept or even rule of thumb.
WET is a clear guideline to avoid usual code quality problems caused by premature specialization and tight coupling which result from DRY fundamentalisms. WET puts on hold the propencity to waste time with code churn. It’s importance is clear to anyone who maintains software.
Not really. Your comment sounds like a weak attempt at revisionism. Some reference books like Bob Martin’s Clean Code explicitly cover DRY and the importance of refactoring away any duplicate code.
WET springs from this fundamentalist mindset. There is no two ways about it.
You wrote:
I’m listing when and how it was coined with the article that coined it. If you have another source to claim it wasn’t in the fashion I’ve described feel free to provide sources to the contrary. I even sources it from the very Wikipedia entry you shared.
Again, feel free to provide sources to back up your claim.
Again. Feel free to back up your claims with actual sources. The concept of AHA by Kent C Dobbs, of Angular fame says:
https://kentcdodds.com/blog/aha-programming
He then goes on to link to the article/blog I mentioned where Durbin states:
And he goes on to explain this new concept of Write Everything Twice.
If you actually interested in discussion about the debate of DRY/WET/AHA, I’m all for it. But don’t misinterpret or try to change what is already well-written.
Also, don’t throw accusations at people who provide you documentation and proof and then contest while providing absolutely none yourself. That doesn’t sound like any earnest interest in discussion.