Stop trying to be so DRY, instead Write Everything Twice (WET)

Conlin Durbin on December 18, 2018

As developers, we often hear cliched phrases tossed around like "Don't Repeat Yourself". We take ideas like this and run with them, sometimes a bit... [Read Full]
markdown guide
 

Yes.
So summarizing: only make an abstraction for something if you can remove three repetitions.

 
 

N = 2 leads to N >= 3 most of the time. I get the point and I also don't abstract out things immediately, but rather than follow hard rules, we can say that ... I don't know it seems like 99% of code is going to be used either once, or more than 2 times. Something to get used exactly 2 times would be very rare.

Also in general programming, abstraction isn't the only way to avoid repetition.

And the main reason for DRY is to not have to change the code in 7 places when something changes.

So you kinda have to know which things logically belong together. Very often that's things that share the exact same code, but sometimes it isn't.

 

I work on more than one web site at a time, all using the same base in-house library toolkit. For each of these sites, they all take a slightly different approach to solving various problems, sometimes related or sometimes not. Once two independent solutions emerge that look like they may be related, the two are pitted against one-another, and then merged together into a single solution, and then pushed into the core toolkit for the rest of the systems to have available as well. This method of parallel development has created significantly better software, because it forces multiple approaches to problems, rather than just a single approach.

The philosophy has been mostly the same as you suggest though, WET rather than DRY. If something is done once? Cool. If it is done twice? Odds are each one will have different advantages and disadvantages. When it comes to doing it a third time, the first two are merged into a single piece of code along with the new requirements, and pushed to the core library.

Doing this, I now have an extremely robust data processing system, user authentication system, path router, HTML templating system, and more all ready to go for future projects.

 

You're basically building your own framework out of your own business requirements, sweet! :)

 

Yup, that's exactly it! And the entire framework is full open source BSD licenced on my GitHub account. The main issue is lack of documentation. This has been one of my main focuses this year and into next.

Good luck, after all that's how both Django and Rails started. They were frameworks used internally in companies

In 2019 we plan on experimentally standing up more instances of the underlying platform that powers dev.to (Emphasis on experimentally)

I'm really excited to see what could come out of extracting this very high-level, highly opinionated framework for building online community spaces.

 

I agree, once Sandy Metz said "it's easy to handle code duplication than deal with a wrong abstraction"

 

That's a good one! As much as I hate duplicate code - tearing apart an incorrect abstraction is a nightmare.

 
 

Sometimes it is more difficult to modify an abstracted component to fit a specific use case.

This is a problem with your abstraction and not DRY. Another commenter mentions a similar problem with having lots of conditionals in their abstractions. That's another symptom of the sale problem, the wrong abstraction.

Also, I'd be concerned about your rubric, "haven't I written this before?" That really only applies when you are the only developer in the code. Hopefully, code review would catch this. I think you have to be a little more conscientious about this in shared code base since no one developer is likely to know all the versions of the same code there are floating around.

But, your point is still valid. Nice summary.

 

One of the arguments for doing it this way is that having three examples to abstract from is more likely to give a generally useful abstraction than the first two. It's not a hard and fast rule though - sometimes when you need the second instance, it's obvious there will be more later, sometimes you find several instances later that the abstraction could be improved and go back to the first few instances to refactor them.
And trying to force a specific use case that doesn't really fit to the wrong abstraction because otherwise you might repeat some bits of it is a symptom of the same problem. Sometimes it means your abstraction would benefit from having parts refactored out separately, sometimes it's better just to have a comment saying "this looks like , but that's not a good fit because ". But if you find the same comment being written three times, rethink the refactor....

 

Also, I'd be concerned about your rubric, "haven't I written this before?" That really only applies when you are the only developer in the code. Hopefully, code review would catch this. I think you have to be a little more conscientious about this in shared code base since no one developer is likely to know all the versions of the same code there are floating around.

This is a super valid point! It's a concern with DRY as well, since if multiple developers don't know the full codebase, they are likely to abstract something multiple times. To me this all comes down to making sure you have well commented code and making team communication easy. Code Reviews also help you catch these problems before they hit the main branch.

 

Articles like this really bother me. Anything that can be done, can be done poorly. That, by itself, is not a reason to avoid doing said thing.

Understanding how and when to create abstractions is not trivial. The end result may seem trivial at times but the skill is something learned and harnessed over time (sometimes over a career).

DRY, like most concepts in software, is more of a guideline rather than an unbreakable rule. Like all good guidelines, you violate them if you have good reason to do so and with a solid understanding (and acceptance) of the consequences.

An article suggesting replacing concept A with concept B because sometimes concept A is done incorrectly adds to the noise developers must learn to filter out as we hone our craft.

For example, it makes no sense to write something again if it is identical to the first. So telling someone to write everything twice is just as bad as misrepresenting what DRY is.

It is better to spend the necessary time it takes to understand your situation and apply the concepts that makes sense there than it is blindly start going against sound guidelines just because it may seem easier.

As an example, consider our old friend the RDBMS. A WET DB can lead to some pretty severe data issues. One would not break normalization on a whim. However, because of the needs of a data wharehouse, a fully DRY DB would be catastrophic; so denormalizing for this very specific use case makes sense. The consequences here a fully know and accepted.

^ RDBMS? Dude! Just use Mongo! :-)
I know. I know. But the point remains the same.

Understand your situation and apply the tools and concepts (and possible modifications to said tools and concepts where reason demands it) that best fits.

 

I can only agree with you.

Also, this WET concept is basically taking a guideline so simple "Do not write things twice, if you can" and suggest a more complex guideline "Write things twice, but not thrice!"

Really? how's that supposed to be easier to remember and follow?

As the old philosophers suggest, we should aspire to the best possible, not the average. Because we're flawed, we will never achieve the best possible but certainly we will achieve better result that whom who tries to achieve the average.

Oh, and the DIV example is horribly misleading. That is not an exception to DRY.

 

So spot on. Thank you for this.

Some devs go to crazy lengths to not write something twice. It's honestly a little silly :).

 

This! And then you have to deal with their crazy abstraction, because they think method names should be the only real “comment”
Sorry, anecdotal example / rant 😛

 
 

On code duplication. I am "lazy" programmer. Every time I start writing a new code I don't care about code duplication. Human's brain tends to duplicate things, it's just tedious to think about good abstractions from the very beginning. However one day, as proper time comes or when I start getting tired of copy/paste (: I look at my code and start refactoring it making good abstractions and reducing code duplication.

 

Same here - I think you're a good programmer :)

Once some of the code has already been written, the problem space and the solution become clearer, and then it's also easier - and makes more sense - to create abstractions.

It's best to realise that when you start programming, you only know about 40%, if that, of the problem space. As we create a fitting solution for the actual problem we learn the other 60% that we were ignorant about when we started. The more we know about the problem space, the better, or more precise, the abstractions are going to be.

 

I love the concept in this post thanks Conlin :)

I also am very in line with the "lazy" programming style. I think it's more intuitive, and helps to not fall on the trap of wrong abstractions, as Ricardo Rivas also commented

 

I get what you're saying, and sort of agree, but I think your examples show a misunderstanding of DRY.

The point is not how long it takes a dev to create a stylized button. The point is that if the button is to be used in several places, there's one official representation of it. That way, it's consistent everywhere, and if it ever needs to be changed, it can be done in one place instead of all over your application so you can miss 3 instances of it and end up with an inconsistent interface. That's a UX example, of course, but the principle is the same for non-visual applications and their underlying APIs.

 

I agree with you! I may not have made it super clear, but I think DRY when applied correctly isn't bad. The examples are definitely a exaggeration, but I think the exemplify the style of DRY programming that can happen when you don't agree on how to abstract or define when exactly you shouldn't repeat yourself.

I think having a rule like "Write Everything Twice" is actually the right way of achieving the same end as DRY. You get good abstractions and you don't spend a ton of time trying to generalize the components you don't need to generalize.

I would argue that it is better to have to miss a single instance and have to update it later than to have too many abstractions that have to be really general or abstract to function.

To me, the best abstractions are ones where you don't feel like you are working with an abstraction. Instead it just feels like the "right" way of accomplishing what you are trying to accomplish.

 

Just wanted to leave this here for people who are interested.

"DRY is about Knowledge, Code duplication is not the issue."
verraes.net/2014/08/dry-is-about-k...

 

Finally some sense in an article and comment thread filled with anti-sense.

You don't "abstract" to avoid duplicating code, you abstract to give names to bits of code so you can think about them easier; for example you don't make functions to reuse them, you make functions to give a name to that operations so you'll think about "create_basket" instead of whatever the basket code does, and work with that abstraction. You don't even need to have that function called twice, once is enough.

Reusing inapropriately code previously abstracted in an object or function might be bad, but "don't abstract unless you write it twice or three times" is worse.

 

This is true, but you have to be willing to spend some time making sure you came up with the right name. Which is of course one of the hardest things in programming ;).

 

This is a great link! Thanks so much for sharing. Gonna update the post to add it!

 

I am more of an advocate of common sense. Experienced devs will write the abstraction straight away but it is never as simple as DRY or WET. If you have 2 use cases you should always think about DRY but when considering this, I try to look at a few things:

  1. How much time it takes to create the abstraction - if I need to spend a week to abstract something I can write in 10 minutes there is no point in abstracting
  2. How likely it is that I will need to reuse the logic - by likely I don't mean in my head but in actual requirements, designs etc.
  3. What are the differences between the 2 use cases and the possible 3rd one - often you find yourself stretching the Abstraction just to fit in a similar use case and that is very bad. A better approach would be then partial abstraction and abstraction composition

So don't be DRY or WET but be smart and use your common sense and experience :)

 

It's not about whether it's the same logic, it's about whether it's the same thing.

If your app features a yellow submarine and a banana, you wouldn't want to abstract out the colour yellow as they're two totally different things.

 

Well you would abstract out the color into a colors constants TBH :D

 
 

I once had to update some SQL in a program and found it had been duplicated four times. No, not four copies, 16 copies! Anyone who thinks that maintaining even two copies of a piece of code is easier than one subroutine or function should not be allowed in a team.

 

Anyone who thinks that maintaining even two copies of a piece of code is easier than one subroutine or function should not be allowed in a team.

Sorry you feel that way Denis! In my experience, the best teams are those that have constructive conversations around these kinds of concerns! I definitely wouldn't want to have to work on that much duplicated SQL, but I still believe there is only so much usefulness to be gained from abstraction. This sounds like a situation where the code would have benefited from abstraction after the 3 time it was duplicated.

When would you draw the line around abstraction? Would it be after just the second time you had to write it?

 

Sorry, I explained badly. The original code was duplicated so there were two copies of it, then those two were duplicated so there were four copies, and so on, doubling each time. (There were some minor differences between copies that were easy to parametrise).

The point is that each copy and paste was a crime in itself, even the first one that only created two copies of a fairly short bit of code.

Saying to yourself, "I'll abstract that later if I need to" is just not good enough as it risks the copies diverging in ways they shouldn't and leaves it up to the next guy to find, understand and fix your mistake or to perpetuate it by applying the same fix in multiple places. Experienced programmers avoid duplication because it makes maintenance harder.

 

Thank you for putting in words something I try to preach within my team!

 
 

I think you forgot to mention important point when it comes to DRY: Dependency. The more code is reused at different places the more dependency you create. This is especially an issue when it comes to refactoring pieces of code into a library. Then you need to maintain your lib, update other services that use that lib, even maintaining multiple versions. So DRY across service boundaries is mostly not a good thing.

A second aspect is

You must comment your abstractions

I am personally a big fan of clean code and this would be a violation to the principles. If you want to add comment, you should refactor or rename the code in a proper manner that reflects what you wanted to comment. If it’s hard find a proper name, then the code probably does too much and violates other principles. If the abstraction is too complex too understand, it probably need to be removed.

 

"I am personally a big fan of clean code and this would be a violation to the principles."

Be wary of dogma. Principles are important in that they help provide a common understanding across a team, but principles are, by definition, high-level --
the reality is that not everyone will agree on what constitutes proper naming or when code does too much. The occasional code comment can go a long way to provide clarity, particularly when there's some unobvious business reason for what might look like strange logic or naming.

 

I agree, naming is hard. But it’s usually worth it. In my team, we only do comments for ugly workarounds with a link to an issue tracker to check if the causing problem has been resolved. Everything else has proper method names. We do that for years now and it’s working great for us. Once in a while, I have to look at other team’s code and find a lot of abandondoned comments that stating misleading or even wrong things in contrast to what the code actually does.
And yes, principles can be ignored in certain situations, but I found almost all clean code principles very helpful worth following.
I thinks the saying is „you have know the rules to break them“...

 

My personal take: abstract, when it sucks.

I don't care if code is written once, twice, thrice etc. Sometimes things are a bit boilerplatey / repetitious, which are a good candidate for refactoring. But unless it doesn't suck to write things over and over there is no need to abstract.

A good indicator for suckiness is how error prone things are: if there is potential error prone code in more than one place, debugging really sucks and then you should do yourself and others a favour in centralizing this part.

OTOH to get this right, you need discipline and experience to not confuse it with sloppiness.

 

I don't know how this article made the subject of the weekly newsletter: "DRY is out, WET is in". This is really not a good practice to follow. I think we should simply understand the basic term of DRY and that's it. When you say duplication is not a problem, things might get out of hand. I agree with some of your discussions, but I still feel that the DRY term has its own importance in both the programming and development world. If you code something twice, it also means you have to maintain and update something twice. This argument can be indefinite.

 

Yes. I take it an opportunity to redo a second time something which I found an way to improve and then refactor the first instance with the new version.

Also to develop a complex piece of code I do it iteratively. First get it working and then iteratively improve it to my satisfaction.

 

A slight correlary, in my mind, is “you’re going to throw away the first one”. Now, what constitutes that one differs like you outlined, but I think this principle serves to reinforce the “write everything twice” - if you’re working on the MVP, no matter how much duplication you have in it, you’re going to be rewriting it later, so save it for later. (But still apply WET in the second round! The Second Version Will Be Perfect is a notorious tar pit.)

 

This article is really dangerous to more junior developers. Copy, paste and change some stuff invites problems, because there may be 5 developers working on one project and if all of them do it just once you have 5 repetitions of something that should be abstracted away. Developers are not monkeys, you should think if something needs abstraction before doing anything, not after you repeat it three times - otherwise you end up with maintainable piece of crap that will need to be rewritten at some point (I had to rescue such projects, it's not fun). If you spend some time actually designing the system you won't have to spew code left and right as you go.

 

When making your code too DRY, it gets burned. :)

You should balance between DRY and WET. I have seen some developers trying to make their code extremely DRY by compressing all the logic, after the process, no anyone can understand the logic. It usually makes the code unreadable. It also usually ends up adding more parameters to the method and make the logic unpredictable and untestable with vary combination of inputs.

 
 

I neither agree nor disagree but I love a good challenge to dogma! Principles by themselves will not create good software. They only point to helpful ways of thinking.

We can end up with too many small abstractions when we abstract too readily and too much spaghetti code when we abstract too slowly. The only thing that will save us is thoughtful design! Oh no! Haha.

 
 

I would also add this excerpt from this post:
csswizardry.com/2014/11/when-to-us...

This rule stems from a slight misunderstanding of the DRY principle. DRY is a principle that aims for a Single Source of Truth within a project. DRY is about not repeating Yourself, it is not about completely avoiding repetition.

If you manually type a declaration 50 times in a project, you are repeating yourself: this is not DRY. If you can generate that declaration 50 times without having to manually repeat it, this is DRY: you are generating repetition without actually repeating yourself. This is quite a subtle but important distinction to be aware of. Repetition in a compiled system is not a bad thing: repetition in source is a bad thing.

The Single Source of Truth means that we can store the source of a repeated construct in one place and recycle and reuse it without ever actually duplicating it. Sure, a system might repeat it for us, but its source only ever exists once. This means we can change it once and that change will propagate everywhere; that there will be no duplication of that construct in our source code; that there is a Single Source of Truth. This is what we mean when we talk about DRY.

 

OMG, thank you. I've been trying to get this out of my brain for years.

 

I've also heard this referred to as the rule of three.

 

Now if you have X devs in a team you can end up with up to X*2 copies of same knowledge/assumptions. When any such assumption turns out to be wrong you have to change X*2 places, but that's not a problem. Problem is finding all those copies. When system gets large this task goes from easy to impossible.

But I guess it is an OK rule for tiny teams and tiny software systems.

 

I once attended a seminar led by Dr. Ralph Johnson (of GoF fame) and he said that we shouldn't consider writing a library or framework until we've repeated using it at least 3 times. So perhaps we should consider Write Everything Three Times?

 

Good post! I personally prefer to repeat as needed better than one complex code with several conditions just to accommodate all known use cases. Repeat makes code easier to maintain and understand.

 

This is usually a sign that your abstractions are weak and you should consider refactoring the code around what's repeated, too. Often it means you have too little abstraction and too much specialization in your functions/classes/etc.

Though as Niels points out, you might be trying to de-duplicated code that's not truly duplicated. Always question the code first, but if you can't come up with a better abstraction, it may be best to leave it for another time. I do agree that a little duplication is better than an over-complicated abstraction. The goal is to consolidate the knowledge and authority to one implementation as much as is reasonable.

 

I agree! question the code first before abstracting code :)

 

If I understand you correctly you’re saying: if I abstract away code, but in that code I have to cater for a couple of different use cases the code inside the abstraction becomes too complex, right?

There’s two answers:

1: it could be that the code you’re trying to deduplicate is not similar enough, in that case don’t deduplicate.
2: there are ways (patterns) to make the code inside your abstractions less complex (basically: less conditionals). For a nice illustrated example of this: youtu.be/8bZh5LMaSmE

 

For me, personally, it depends on whether the non-dry stuff is a true repetition of business logic, of the domain specific stuff, of the requirements set forth by end users.

If people in the business give it a name ("the user registration process", "subscribing to a tag") it must be dry, even if only used twice, to avoid bugs.

If the repetition however is due to composition, further abstraction often hurts the code. You might often remove the first item of array, then filter invalid stuff, then reduce it to an aggregate — doesn't mean it must hide inside a tailFilterInvaludReduce() method. Leaving the composable bits composable is often a good thing, because method names can lie about their contents.

 

Interesting article Conlin!

I think that team sizes also affects WET and DRY. WET might not be preferable for bigger teams because you need to acknowledge that you wrote or at least saw something similar before.

DRY on the other hand, is arguably currently dealt with using code analysis tools (and probably why 'knowledge' takes a back seat). So the use of code analysis tools here makes it easier to implement in bigger teams. You can argue that you can do the same in WET though.

What's your thoughts on this?

 

Honestly we'd be far better off if too many people tried to DRY out their code. I don't know who it is that you work with but I see copy/paste garbage all over most codebases I look at. The people I'm working with are in no danger of making their code too DRY. And I don't believe I'm alone in that.

 

You are confusing two very different concepts.
DRY is not about code: it's about the model (representation).
It's about having a "single source of truth". There is no "premature optimisation" whatsoever in that. It's just good programming practice.

What you are talking about is implementation and levels of abstraction. There you can have premature optimisation and over-engineering, and you sure need to be careful with that. But it has nothing to do with DRY.

 
 

I think WET applies more from a UX perspective, but if you are doing programming in c# or java or any object oriented language, DRY principle applies.

 
 

DRY it's from OOD principle and those principles they are the most powerful design we use to enhance back-end, your suggestion is not valid for this side of programming, it may apply on UI/UX.

 

While I do think there is more need for DRY principals on the backend, there are many functional languages that do not use OOP at all. Even within OOP languages like Java, premature abstraction can hurt you. Abstracting two classes into a higher order class could cost you if the abstraction is too generalized.

 

OOD is not OOP first, OOD is general design patterns for software development, you can use OOD in many language that they are not oriented object i.e php...
For abstraction you may right, but also OOD handle that in general matter.
The rule of three that it's similar to your suggestion can apply also with DRY, it seems opposition but DRY doesn't really means DON'T REPEAT THE CODE Like many understand, DRY is DON'T REPEAT YOUR SELF in intelligent manner so when low level piece of code have same sense in one module create abstraction for it.

 

Thanks for giving it a name and for the fantastic explanation!

 
 

I call this DRY (Do, rather yanking).

A lot of attempted DRY code i saw, have enough parameter additions, and conditional statements.

 

So we can repeat

's without much issue and I don't think anyone will take offense at it.

...

Divits spotted.

Aaaand markdown is broken. Way to go!

 

There should be a tag called #common_sense and this article should be assigned to it.

 

I always do that, i allow me to repeat code two times, if i need it by third time, i refactor it.

 

Ned Batchelder has a saying that "the right time to automate something is when you're tired of doing it by hand." Similar gut-feeling basis.

 

I call this "Pragmatic Programming", and it's the good way to go with the design principles.

 

WET is not at all a solution to the problem you're describing. You're talking about problems when DRY is either misinterpreted or taken to an extreme level of granularity. Even twice the amount of code is too much as long as you're not measuring that all the way down to the atomic level. Atoms or single tokens don't particularly count when it comes to DRY. What you're saying is DRY is invalid because then you couldn't use the same word twice.

When people say that they mean saying the same sentence twice or the same paragraph. It usually only applies to single words when they're redundant. In this case we might be talking about a div inside a div with no reason for it.

Taking the term literally shows no real experience of what it actually refers to which tends to be more excessive redundancy than anything else. Using a word twice in a sentence such as in this sentence is not redundant. In fact lexically two blocks of code need not be the same at all to violate DRY. They just need to do the exact same thing and for the code to work the same if you remove one and replace it with the remaining. The obvious case of a violation of DRY is going to be straight duplication.

While there are guidelines there isn't a perfect set of rules for DRY that can be followed by rote without thinking which is what seems to be attempted with WET.

As far as I'm concerned the people who struggle with DRY will struggle the same with WET.

The problem isn't whether red or green is more visible. Some people are just blind. If they can't get a sense of DRY after a sufficient amount of practice then they should question if they really have the mind to fully master the art of programming. DRY really isn't something you should need to be told. You should work it out from programming a few things. If you don't work it out you're lacking the ability to move beyond a certain stage.

If that's the case I have no problem with that. Some of my best developers had astonishingly low ceilings. However they stayed humble and did what they could do and do well. Despite their ceilings that also enabled them to progress in all the areas where they weren't capped off.

It's another thing to be hostile and attack developers that can produce better code by making manipulative arguments to make out that better code where people can better implement DRY as well as give better examples to learn from is bad by pointing out nonsensical cases of terms being interpreted in the most extreme manner. That's just deliberate sabotage and it's on you.

If you were criticising people taking things to extremes fair enough but this is where it's subtle, that it then used as an excuse for writing bad code or in this case WET.

code of conduct - report abuse