DRY is an over-rated programming principle?

A better formulation of DRY is SPOT (Single Point Of Truth). Definitions (code, data) that represent the same “truth”, i.e. when one changes all have to change to represent a consistent truth, should be reduced to a single definition. For example, if there is a rule that pizzas need at least one topping, there should only be a single place where that condition is expressed, so that when the rule changes, it isn’t just changed in one place but not the others. Another example is when fixing a bug, you don’t want to have to fix it in multiple places (or, more likely, neglect to fix it in the other places).

Every time I read an article like this, "why <often cited best practice> is overrated", I think, yeah you are right in theory. But most places I have worked, these best practices were not overused, but underused. If you have the problem that your coworkers create unneccessary abstractions, I envy you, because I have so often had the opposite problem. Maybe this is not the case if you work in a great software development team. But if you work somewhere where they do software development on the side (science, hardware, etc..) it is the main issue.

People not able to factor out functions or structure their code in a readable way. Variables are called v1, v2, v3. Unit testing seen as a waste of time. CI seen as a fun toy. They lack the experience to even notice the difference.

Maybe I'm becoming a curmudgeon, but I think many people would be well served by just googling "<my programming language> best practices", learning the acronyms like DRY, and just following them. And when you have gained some experience, sure, then you should question the wisdom and not follow it blindly.

> Instead of our code being architected around the concept of how pizzas are made in the abstract, its architecture is tightly coupled to the specific needs of these two pizzas that we happened to be dealing with. The chance that we will be putting this code back the way it was is extremely high.

Mistake 1: Switch from DRY to premature optimization.

> You might think that legit reasonable developers but would not actually do something like this and would instead go back to the existing invocations and modify them to get a nice solution, but I've seen this happen all over the place.

Mistake 2: Assumption of incompetence to support your argument.

> . As soon as we start the thought process of thinking how to avoid a copy paste and refactor instead, we are losing the complexity battle.

Mistake 3: Strawman argument. DRY does NOT lead to over-complicating things. Overcomplicating things leads to overcomplicating things.

Now, i wasted 5 minutes, so you can waste some more to reply to this comment, instead of completely ignoring this dumb random blog post.

Wtf.

If your use-case is that the user can select the crust, sauce, cheese and toppings for a pizza, just pass that shit to the make_pizza function with the help of enums and arrays. If you want to have predefined pizzas, you'd simply make a dictionary of pizza templates with all the options that the make_pizza function needs and/or if you wanna be fancy, you'd make a separate make_pizza_from_template function, but definitely not a make_pepperoni_pizza function, because that's just encoding data as a code in a silly way that arguably not even a factory pattern.

No solution will be able to cater to requirements that don't exist at the time of developing this pizza-application. You build it according to the requirements that exist and that is enough. It's not your fault if nobody cared to mention that the user should be able to arbitrarily subdivide the pizza and select options sepatately for each subdivision - that's a feature update and it's OK if the original program hadn't though of that. Just like you wouldn't scaffold ecommerce capabilities into a webpage "just in case", if there had been zero mention of such a need.

Not sure why this is on the frontpage. Not only are there a bunch of typos, a bunch of code doesn't actually work the way they said it does. Also gotta love hating on the 10x developer or whatever for saying you are wrong.

EVERYTHING HAS TRADEOFFS. Every single thing has tradeoffs. Obviously you should not write terrible, brittle code. The reason DRY is important is because when you start duplicating code, having 30 different serialization methods littered throughout your code, 5 different ways of calculating the same value, etc etc you see why it really matters. Its a GUIDELINE used to as a general rule. And as guidelines and general rules go -- its useful for juniors and people who don't have the experience to see the best way to write the code.

Its a good default, and like YAGNI, and 100 other programmer acronyms it has its ups and downs. Your pizza example is not "coincidental repetition" -- it is actual repetition -- you just abstracted it in a really poor way to make a strawman.

In this case, the problem is with a bug creeping in:

            crust: "thyn",

DRY is about avoiding this class of cut-and-paste bugs too. Or with changing a string to a token, as it should have been:

            crust: THIN

The code isn't even correct. It's mixing JavaScript and Python. I'm also not sure why you'd declare functions for each type of pizza; that's data. I'm not sure about the context, but the right way is:

    def make_pizza(crust=THIN, toppings=[], cheese=REGULAR, sauce=TOMATO)

and then in each call, to override.

    make_pepperoni_pizza()

is bad code compared to

    make_pizza(toppings=[PEPPERONI])

All of the code in this post is horrible, and has easy solutions.

I feel dumber for having read this post, and even dumber for having responded.

Surely you'd remove repetition by doing this instead:

    hawaiian_pizza = {
        crust: "thin",
        sauce: "tomato",
        cheese: "regular",
        toppings: ["ham", "pineapple"]
    }

    pepperoni_pizza = {
        crust: "thin",
        sauce: "tomato",
        cheese: "regular",
        toppings: ["pepperoni"]
    }

    def make_pizza(pizza):
        requests.post(PIZZA_URL, pizza)

This isn't better just because it's DRY, it also keeps the data separate from code, which makes it usable elsewhere. Defining fifty different types of pizza inline inside functions is a strange choice, because it tightly couples your pizza definitions to your pizza-making. What if you want to answer a question like "how many thin crust pizzas do we sell?"

I see DRY as a smell, not a principle. If you see clones (same code in multiple places), then it's likely indicating that there is something that can be factorized. Now the question you should ask yourself before factorization is whether the duplication is coincidental (as the author shows) or if it's because the logic was copy pasted. Most of the time it's the second case, and duplicate code does make maintenance harder and riskier.

One of my pet-peeves is clones in unit-tests. People tend to care less about code quality when it comes to unit-tests, and code gets copy-pasted all over the place. The result is usually an unmaintainable ball of mess, where the most subtle variation in the unit being tested requires you to apply the same change in 15 different places. In this situation, DRY is a very useful indicator that something is going wrong.

Now the opposite of DRY is YSHRY - You Should Have Repeated Yourself. When you start adding 5 boolean parameters to a function to adapt it to all its calls, it's a smell that you thought you should have DRY, whereas YSHRY.

DRY and Once And Only Once isn’t about slavishly identifying similar code blocks. It’s about trying to arrange your code so that a single idea is expressed in a single place.

The initial API here is actually quite nice - there’s a good separation of abstraction and specification, and I can see all the information about an individual pizza in one place. The idea of making a pizza and the recipe for each pizza exist once in their respective places.

It’s true that a common pitfall is to prematurely create abstractions before having concrete examples of how they’d be used. But DRY is a _refactoring_. It’s something you do to an existing codebase to better clarify its design, not necessarily something to strive for ahead of time. Much better to extract abstractions from existing examples.

I always remember the tale Ron Jeffries tells of Kent Beck actually _introducing_ duplication to allow both pieces of code to be refactored. Duplication can be an opportunity to refactor towards a clearer design, but it’s not a mechanistic thing to do without thinking.

I am working in a code base right now that was literally ruined because of #3. It's full of extremely difficult to follow and test higher order functions that are completely unnecessary. A feature request did come for a "half/half" pizza and we're spending our days trying to disentangle the higher order functions.

The developer who wrote this thought himself the programmer genius and wanted to make a pattern out of everything. He did not accept criticism because "DRY is a holy principle".

And that is why a post like this is important. Because next time I have someone like him in my team I can point him to this post. Argument by Authority may be a fallacy, but it is significantly more persuasive than other arguments.

And yes, you can respond to this with "why did you hire this guy in the first place, or why did you not fire him?". Well I do not make all the decisions. Not every teammate is perfect. Such is reality. Particularly in such a young industry as software development which (compared to, say, electrical engineering) is still searching a common understanding of ubiquitous best practises.

> I suspect any developer reading this is aware of the DRY principle because it is just so ubiquitous. If not though, you just need to know that it stands for "Don't Repeat Yourself" and is generally invoked when advising people to not copy and paste snippets of code all over the place and instead consolidate logic into a central place.

Well, no.

What you actually need to know is the next layer out: DRY stands for Don't Repeat Yourself, sure, but Don’t Repeat Yourself isn't the rule, it's a short phrase that is supposed to be a memory cue for the principle “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”.

If all you know is “Don’t Repeat Yourself”, you don't know the principle, and you can neither apply nor critique it.

#1 is simply applying the memory cue as if it were the principle. Yeah, don't do that.

#2 is, well, no, you only refactor to extract a bit of knowledge to a common place where it is immediately reused: there is no presumption of reusability, it is demonstrated.

The specific example they use of how this might be done wrong is...so bad.

Starting with: the example code that they suggest is bad design but works does not work.

  make_pizza([left_topping, right_topping])

gives args a length of 1, not 2, but their function definition relies on it having length 2, and using that to distinguish from the simple case.

Personal anecdata. I have been increasingly aware of my own mental patterns during development and I've noticed that often I've been sitting and mulling over refactoring to some sort of universal solution instead of getting on with the work and getting things done. There are instances when I could've finished the task twice as fast if I would've just went ahead and done it with repeating code instead of thinking of clever ways to DRY it.

Therefore for my personal projects I'm now firm believer of quick iterative building. Just get the first iteration done, get it working and save improvements for later. It may create a bit more work for the future me but it decreases the mental load quite significantly. I'll take less mental load with clear objective (refactor this because this) over more mental load with unclear objectives (make universal solutions taking into account things that may or may not happen in the future) any day.

  left_toppings = ["beef"]
  right_toppings = [] 
  make_pizza([left_toppings, 
  right_toppings])  # this will be a very funny pizza

Holy cow I was not expecting a none pizza with left beef reference in code form

Something I have come to feel myself but haven't found a good way to articulate is asking "is what I am doing favoring authorship over maintenance?". I find that a lot of times the way DRY or other programming principles are used tend to be done to optimize authorship. This optimization sometimes happens at the expense of maintainability.

Anticipating maintenance is tricky; I had a scenario where a developer on my team created a utility function to abstract away some code that was being repeated multiple times in the same file. As an author that made sense because he was writing the same code over and over again, but down the line when we wanted a specific instance of this copied code to work in a slightly different way we ended up making the utility function handle the edge case.

Over time this utility became extremely hard to work with, because you weren't always sure if you made a change it wouldn't create a regression in other places it was used.

When we sat down and asked ourselves "Is this utility assisting in authorship at the expense of maintenance", the answer was clear. We removed it and put back the repetitive code. We felt good about it because in reality, 90% of the time we were interacting with this code we were doing it in maintenance mode, tweaks and small updates. When in maintenance mode I don't feel the strain of a specific part of my code being repeated, I'm only looking at a small subset of the code. Sure, if I need to author a new case in this code it might be a bit more wordy, but I think the tradeoff is worth it.

I am sure there are perhaps better ways to abstract things, or that we were doing DRY wrong, and our utility function could have been smarter, but I've seen this same thing play out over and over again and usually trying to make my abstraction better hasn't helped.

I have reached similar conclusion. DRY projects tend to snowball over the years into mess where every minor change is insanely difficult, breaks everything and code is hard to read, bugs are difficult to solve, diffs are difficult.

WET code (opposite of DRY code, often starts as copy pasted) has more code, more typing, but the diffs are simple, bugs are simple (often you simply forgot to copy piece of code into 7 different places which is easy to solve). After many iterations, what started as very similar "classes" is now completely different.

One look at WET class and you know what it does, you change one line and you're done, maybe you need to copy it to 2-3 other files, maybe you don't. In comparison, you'll stare at DRY class for 2 hours and realize you need to refactor absolutely everything, it will break half of the codebase and diffs are insanely complicated.

I've recently wrote 2 similar projects, one wet one dry and wet one is simpler, easier to maintain, and more enjoyable to work on. Dry is root of all evil.

Especially if there is a very common refactoring bug and you get a pepperoni pizza instead of a pizza with one of the most natural toppings like pineapple.

But I tend to agree with the author. Sometimes verbosity is the lesser evil. No suggestion should become a dogma and whoever played some games of code golf knows that short code doesn't mean code that is easy to read. Extreme example of course. But I believe many start to optimize in this way just as a way to reduce the line count.

Still, there is still room for some kind of factories or function templates (not in the c++ sense). I think a user is allowed to repeat himself but then again a user is just another arbitrary layer again. But if such helpers are to be implemented, I tend to like it in a place where the user is invoking said helpers and not on the level below that if that makes sense.

What forced me most to use DRY in inappropriate ways is typing out blocks of the same code again and again. Then I realized that and began to maintain and use easily expandable snippets with fillable placeholders. It turned out that my mind had no objections against repetitive code at all, and the clarity of it has only increased, due to the lack of context switches and parametric entanglement.

I once worked on a project that was basically a simple My Account application/area for a train ticket retailer.

The backend itself held no data, but whoever built the backend had gone full service layer, with models and adapters to the upstream services that hold the data.

The result was a backend that was a pain in the ass to change, necessitating whole trees of file changes to build features.

So we started inlining everything. We just took it back to the request handlers. We started fetching, mutating and returning the data in the request handlers. Suddenly a change became modifying one function. Every endpoint was unique and didn't depend on anything else. Things became easy.

Halfway through the migration, someone got our effort reviewed by a principal engineer who told me "it wasn't SOLID", and my contract wasn't renewed. It didn't dishearten me.

Software design is meant to make change easier and proudly adding abstractions can be a bad thing.

IMO, DRY is the second principle, the first one is KISS. It is preferable to repeat ourself if that contributes to simplicity and ease of maintenance. My third principle is that there is only three principles.

As with any such article, it comes down to competence mistaken as principle. Principles are never, here, to blame. A cultish (inexperienced) belief in the sanctity of a principle is to blame.

Excellence in programming is trading principles off each other based on the design constraints and expected changes.

DRY trades off everything else in different ways depending on the language and problem. DRY in python should, often stop when you ask "should this be a metaclasss" but before "should this be a decorator", that's different than in C

> "Had we started out with two pizza types that have different crust/sauce/cheese, we never would have made this refactor. Instead of our code being architected around the concept of how pizzas are made in the abstract, its architecture is tightly coupled to the specific needs of these two pizzas that we happened to be dealing with. The chance that we will be putting this code back the way it was is extremely high."

Maybe.

But maybe you're falling prey to the other programmer trap - catering for conceivable situations that are just never going to happen, and making your codebase unnecessarily accommodating as a result. This is another great source of complexity, and quite often the source of unnecessary abstractions (which add to cognitive load) too.

In my experience it's better to cope with half-and-half pizza toppings when they arise, rather than coding as if they're already needed. Because when they are needed, you'll probably find the requirement is actually to put them on a 3-tier wedding cake, or a car.

I often find that DRY is in conflict with Conway's law[1]. It's almost always better to let Conway's law win. If I help write a build script for one team, I often copy and paste it into another's git repo to instead of trying to share it. It's often way better than factoring it poorly[2] or getting the two teams to coordinate on changes they need to make to it. Best to let the two copies diverge in that case.

1: https://www.wingolog.org/archives/2015/11/09/embracing-conwa...

2: https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

I think there are three levels of understanding this topic:

1) Repeat yourself everywhere because you're a noob and don't know how to DRY

2) DRY everything because it's easier to maintain, learn all sorts of clever tricks to make DRY work

3) Realise that sometimes it's easier to DRY and sometimes it's easier to write repetitive code.

The problem is that if someone at level 3 (like the author) talks to someone at level 2 then the level 2 developer thinks that they're talking to a level 1.

The general approach is to refactor/generalize when creating a third version of something. With the first thing, you don't know if it needs any common functionality or what an appropriate abstraction will look like. With the second thing, you have some similarities but not enough information to know where the abstractions should be -- here, repeating yourself is OK.

With the third thing, you should have enough information to work out where generalizations should be. Even then, only generalize what you need to at the time. Going overboard can add unnecessary complexity, so it is generally a good idea to be conservative in what you generalize.

As you add more things, you can refine and evolve the system as needed. At this time you should have a better understanding of the system and what parts can be shared and generalized.

I've tended to approach refactoring common functionality based on whether two pieces of code are either "coincidentally" the same or "intrinsically" the same.

If code is coincidentally the same, then you should leave it alone - the two pieces of code are likely to evolve independently and trying to make a common function/class handle two separate usecases is likely to lead to complex, ugly code.

Conversely, if the two pieces of code are intrinsically the same then you SHOULD pull them out into something common. If you don't, you risk the implementations drifting and getting inconsistent behaviour over time.

Determining which is which is a matter of interrogating your domain and business logic, which is the essential function of our job as developers/engineers.

Two instances isn't worth consolidating because it's hard to know whether the similarities are real or coincidental. Check out the rule of three: https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...

> "All these ideas are great. But remember that the fundamental goal here, is to send a POST request with a single JSON object."

This. A million times this.

IMO, the single most important principle is still "Keep It simple when you can, make it complex when you have to."

A system that is simple can be grokked quickly, meaning it can be debugged quickly, modified quickly, new developers can be onboarded quickly,...

Yes complex systems have to exist. Some tasks are complex, and require complex solutions. BUT: Complexity should come into play when it is necessary.

It is perfectly okay to design simple solutions for simple tasks. Yes, sometimes this means ignoring things like DRY.

I disagree with the author's example as given.

The example discusses a code boundary that is internal to a single atomic "module" - the preparation of a data structure that describes a pizza. Then the author says that bad things will happen if said code boundary is used from other modules.

However, why would an extrenal module developer do that? It is common wisdom to recognize and avoid module-internal utility functions.

Conversely, as long as the presented shortcut is internal to a module (=used only for a specific set of use cases well understood by anyone touching the code), and saves toil, it might actually be justified.

Have you ever seen the complete opposite? non-DRY all over the place? No variables or constants defined, same values manually inserted all over the code? Or same code with slight differences duplicated all over the place. - When you see that, you'll realize how useful the DRY principle is.

"I figured I'd kick off my new blog with the most click baity thing I could think of."

Then write: "Why i prefer tabs over spaces!" let the flamewars begin

The article is actually good. The criticisms of DRY here are valid! For criticism 1, I had a coworker once say something that resonated with me:

"Just because two things are the same right now doesn't mean they _should_ be the same."

So that criticism is totally valid - DRY has to be applied only when things _should_ be the same, and that can actually be hard to identify.

That being said, of course the title of the article is bad and not accurate. DRY is essential. I don't think there's many people that actually argue against it. If you have a piece of business logic that's essential to the business and it influences other pieces of logic, they all have to refer to the same definition. Repeating it is bad for everyone - users will see inconsistent behavior, and devs will have to "remember" (read: never actually remember) to update important logic in multiple places. Important things should have a single source of truth. That seems inarguable to me.

It can be hard to find a design that actually achieves that. That's not DRY's fault.

The code in the second example is horrible and for some reason used incorrectly by the author.

My usual approach would be something like:

    def make_pizza(left_toppings, right_toppings=None):
        if right_toppings is None:
             right_toppings = left_toppings
    
        ...

through really it should probably be

    def make_pizza(toppings=None, **kwargs):
        if toppings is not None:
            kwargs['toppings_left']  = toppings
            kwargs['toppings_right'] = toppings

        return requests.post(PIZZA_URL, kwargs)

If this logic should even be handled in the application itself at all (not sure why you'd choose to make a breaking change to the API rather than extending the API, though changing the make_pizza function to keep the code working after an API change is the correct response).

I'm also not sure why the author chose to make the function capable of handling an arbitrary number of arguments, or why after doing so he chose to incorrectly invoke it on a list.

The big deal is that when a boundary exists, DRY should be "ignored" (cannot word this decently).

For example, let's say there is an application where a user can purchase items and also give reviews for such purchased items, the user reviewing and the user buying have in common just the ID, while in the review boundary the relevant information is probably the user nickname, while in the purchase boundary the relevant information is the payment system, or the state of the checkout ("purchase" is probably not a single boundary).

In that case, data could be duplicated to ensure the boundaries are decoupled.

This is of course at the data level, but usually it translates to "there is a user model that has many orders and many reviews", because of DRY, no two user models could exist, there you have the boundary violation though.

Sorry, this is a bit of a ramble, it's a long discussion.

> Now we are talking about all kinds of fancy programming stuff to try to solve problems that only exist because we don't want to repeat the same 6 line snippet in a handful of different places because DRY tells us that's bad.

Oooh yeaah ... I have had that exact argument in the recent code review where patch literally modified _hundreds_ of LoC across many different files just to avoid duplicating a simple 10-liner at a single place? Yeah, you read that right.

A developer basically rewrote half of the existing code architecture and applied "best" OOP practices. Intention wasn't a bad one but it is unnecessary to say how incomprehensible code would have become if that patch went in in its original form. It was hard to argue against it and what would have been a 10-minute work it became a 2 or 3 week long discussion. And that is just ... bad.

The biggest issue with DRY is commitment to a bad abstraction just for the sake of not copy-pasting some code. Abstractions should be liquid while you're figuring out the best way to model your problem, and DRY can often be a culprit in having a model that's a bit too rigid.

Obviously YMMV.

Despite the backlash in the comments, I have to say I agree with the article. I realized eventually that it's our job to produce solutions, and not write code. Engineering (at least for software) is about making a computer do something novel, or if not that then making easy to adapt. Creating code that is nice and elegant, DRY, is about engineering code, but not engineering a solution. If it helps make things easier then sure, but despite the simplicity of the examples I think they demonstrate what everyone has seen -- this one nice to have function or whatever turning really ugly from trying to handle all of the edge cases. At that point it becomes nice to not have, but it's too late.

Also, I liked the comment from ihateolives somewhere in the thread a lot.

"Duplication is far better than the wrong abstraction" - Sandi Metz

https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

The very first "refactor" is broken, the last line should be `make_pizza(["ham", "pineapple"])`. Which is actually very easy to notice if you actively watch out for repetitions.

Ironically the author just demonstrated why DRY is a great principle.

If I can be a little too honest here, I will admit that I just don't like making programs that are too simple. I can make an extremely simple program... But it doesn't feel good. I know there will be limitations to that simplicity, and I want to make functions that do things, and combine those functions, and let them override things, and pass state, transform state, etc. Making it complex just feels better.

I actually stand outside my body and watch myself make it more complex, and think, "Ugh, this is more complex than it needs to be, I should make this simpler. But I don't want to." I continue and hope that a refactor will make it less embarrassingly complicated.

A Philosophy of Software Design by John Ousterhout goes into some of these ideas a bit. To me, the book takes an approach that is somewhat contradictory to Clean Code (a bible to many), but in a rational and well explained way. Lots of talk about over abstraction which can end up complicating code reading in the long run.

An idea I've seen a lot here on HN is that DRY is good with a baseline number of reuse. If we see the same pattern twice, maybe it's not a good abstraction since we haven't seen it grow yet. If we see that same pattern 15 times, I think we know an abstraction is handy here.

Perhaps the problem is that we've stopped teaching people about coupling and cohesion, along with the mechanism of stepwise refinement.

We abstract to functions to reduce cognitive load and to allow scope rules and information hiding within the language to prevent local variables becoming pseudo globals.

The whole premise of the 'goto consider harmful' structured programming movement was to allow us to replace control structures with a single black box consisting of input-process-output, which aided in reasoning.

The premise was to construct the program from cohesive functions that are lightly coupled.

When did we move away from that?

Notably, this already starts dry.

A less dry one would look like

def make_hawaiian_pizza(): payload = { hwaiianCrust: "thin", redSauce: "tomato", cheese: "regular", ham: true, pineapple: true, toppings: ["ham"] } requests.post(PIZZA_URL, payload)

def make_pepperoni_pizza(): payload = { pepperoniCrust: "thin", crust: "thick", sauce: "tomato", cheese: "regular", toppings: ["pepperoni"] } requests.post(PIZZA_URL, payload)

We could move away from prescriptive "programming principles" and towards ideas that empower people to use their own judgment. Instead of "Don't Repeat Yourself", it could be "You Don't Have to Repeat Yourself".

Now I know what I'm getting myself into here. Most people hate making their own choices and love to blindly follow simple prescriptive rules which are known by Experts to produce Good Results. But when the religious approach isn't working for you, maybe it's time to stop making your occupation a religion.

People should reconsider writing articles like these. It's just a list of (3!) criticisms. You can still have your click-baity title, but why not write about when and how to use XYZ principle instead?

As anything it is just a tool in our toolbelt and should be used carefully. If our system contains same user validation in 2 places, changing it in 1 place may lead to issues, which are difficult to discover. However forcefully implementing DRY everywhere can lead to coupling and lack of separation between modules and influence deployments, and work of different teams. Its more difficult to build context of the implementation, if one needs to jump from file to file. There’s a balance to when to use it or not.

What about something like this (in JS)?

  // Option 1
  const Pizzas = {
    Hawaiian: {
        type: 'hawaiian',
        crust: 'thin',
        sauce: 'tomato',
        cheese: 'regular',
        toppings: ['ham', 'pineapple'],
    },
    Pepperoni: {
        type: 'pepperoni',
        crust: 'thin',
        sauce: 'tomato',
        cheese: 'regular',
        toppings: ['pepperoni'],
    },
  };

  // Option 2
  // Pizzas could be returned from an API, so that the pizza 
  types are configurable outside of the code
  const response = [
    {
        type: 'hawaiian',
        crust: 'thin',
        sauce: 'tomato',
        cheese: 'regular',
        toppings: ['ham', 'pineapple'],
    },
    {
        type: 'pepperoni',
        crust: 'thin',
        sauce: 'tomato',
        cheese: 'regular',
        toppings: ['pepperoni'],
    },
  ];

  const makePizza = (pizza) => requests.post(PIZZA_URL, pizza);

  // Then, for Option 1
  makePizza(Pizzas.Hawaiian);
  makePizza(Pizzas.Pepperoni);

  // Or, for Option 2 (e.g. user selected via a menu)
  makePizza(selectedPizza);

> All these ideas are great. But remember that the fundamental goal here, is to send a POST request with a single JSON object. That is a very, very simple thing to do. Now we are talking about all kinds of fancy programming stuff to try to solve problems that only exist because we don't want to repeat the same 6 line snippet in a handful of different places because DRY tells us that's bad.

Yes, that is a very common beginner mistake. Sometimes a little copy-pasta is needed to avoid over-complicating what needs to be simple.

Where DRY is really important are things like:

- Hey, you seem to be using "foo" and "bar" all over the place. Put those strings in constants.

- Hey, you're using magic numbers all over the place. Use an enum (or constants depending on your language / situation.)

- Wow, you copied and pasted that logic all over the place. Now when we need to make a change we have to make it in 20 spots. That should be encapsulated in a function / method / object

- (And to get closer to home) Even though you just want to "send a POST request with a single JSON object," we have a common session management pattern and error handling pattern in our application to deal with this API. That particular pattern should be encapsulated so you aren't repeating it for every #%$#@ API request.

DRY is about code, not data. If you see two methods do the same thing somewhere in their code blocks, separate the duplicate logic into a separate method, then call that method when you need to execute that logic.

The reason for this is maintainability. Say that logic needs to be changed. If you didn't break it out into a callable method, you'd have to find all the places you use that logic and change it. If it is a callable method, you only have to change the logic in one place, thus DRY.

https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

Here is an overly simplistic example:

If you see this scattered around your code:

  var formattedName = firstName + " " + lastName;

Create this method and call it when you need it:

  string FormatName(string firstName, string lastName)
  {
    return firstName + " " + lastName;
  }

  var formattedName = FormatName(firstName, lastName);

When business decides it wants to change name formatting from "firstName lastName" to "lastName, firstName", you only have to change the logic in the FormatName method because you "didn't repeat yourself."

This article's conclusion and headline is shallow. The example is a good one about where (depending on context), adding abstraction to reduce repetition might add complexity. Great point! Repetition is fine in reasons like that.

It does not invalidate DRY concerns in general! For example, an important reason to avoid repetition is that it adds maintenance inertia. Where a setup that a single-location change is easy to experiment with and improve, one that's repeated several places becomes tougher to change. Ie, friction. I would argue this is also adding complexity - what the author seeks to avoid.

You could imagine contexts for the pizza example where the repetition doesn't make sense, and a refactor could make things easier. You can't tell alone from the snippet.

From the headline and concluding paragraph, it feels like a straw-man. eg overrated, and:

> "Well, obviously I'm not saying we should throw DRY completely out the window. I'm not sure it would actually be possible to write code that "never doesn't repeat itself". But I do think we should tone down knee jerk reactions to PRs that contain several repetitions of a block of code. There are at least a few cases where that might be the exact right thing to do."

> but I would assert that any change that doesn't modify the existing calls of make_pizza or make a totally separate function for split topping pizzas (not DRY) will be some level of bad.

You make a make_pizza function that supports split toppings and you pull the guts out of the original make_pizza function that just calls the first make_pizza function with left_toppings=[toppings], right_toppings=[toppings]. You don't need to ruin your function signature with *args.

The fundamental assertion is that you should be structuring your code such that it is reflective of reality, but reality is really bloody messy. The immediate response to this example is that Pizza is in fact Toast[1] and so you should actually have a make_toast function that handles all forms of toast. This is clearly ridiculous, and if you're building a system to make pizzas and you build your function in a way that extends as far as building nigiri sushi, you're an idiot. You have to take a reasonable judgement of what is the underlying structure that you want to reflect. It's not a coincidence Hawaiian and Pepperoni Pizzas are structure the same.

[1]:https://cuberule.com/

This is like saying "database normal forms are overrated - they make my SQL more complex and harder to read!"

Well, yes, they do. They also make your database slower. This doesn't mean they are overrated - this means they are tradeoffs. Like everything engineering.

With DB normal forms you buy integrity (i.e. keeping the data consistent as it changes) and you pay with performance and schema complexity. Usually this is a sensible tradeoff because integrity is more important. But, for example, if your data never changes - you will be paying for nothing. Or, perhaps, you can't afford the performance price and you have some other way to ensure integrity. Then you de-normalize.

DRY is similar. As mentioned in the sibling thread, it's not about mechanically avoiding repeated code - just like normal forms are not about never having the same value in two different rows. It's about maintining logical integrity of your code as it changes. PI=3.14159265359? Probably safe to copy around. An implementation of some use case? Probably not.

I'd say following DRY/STEP principle is a sensible default. If a reviewer asks you why your code is not DRY - you should be able to articulate a reason.

Thanks for this article, I was just talking with my colleagues about it. And didn't find something simple to share with them, so this was just what I needed.

I think DRY is a good thing in some cases, but you should careful consider when something is worth to DRY and when rather WET gives you the best tradeoff for isolation.

My metrics to decide is to stick in favour of the Single Responsibility Principle. If DRY means compromising it, most likely is not worth it.

Probably the most common comment from me in code reviews is about code being prematurely DRY’d out. Fortunately, I’ve found that mentioning the Rule of Three is usually enough to correct it, and it tends to stick in the mind. Waiting that little bit longer, more often than not there’ll be no third instance of some pattern and no need to abstract it. When a pattern does emerge, it’s a clearer one. Either way it’s less work.

Except, once you are done, you probably never have to touch that code again, and creating a class does not really take long.

Depending on the given problem, this is sometimes more time consuming, but still gets easier and faster with practice, and the benefit down the road can be tremendous.

Associative arrays are bad even for such simple things imo, because it breaks autocompletion / code inspections, and your functions are then these blackboxes that are hard to understand without looking at the implementation (code). Sometimes this is also evident when it's just you working on the code; try leaving the code for a few months only to return at it, and waste time relearning how to use your own code, because it is not self-documenting, and you can also forget- or misspell an array key. Etc. This is not the case if you define data types as objects instead of using arrays.

I learned this from trial and error myself, and I used to use associative arrays a lot for things – now I find myself using/creating objects more often, and I just love returning to this code later, and have it work without too much crapping around.

Uh, no. Like your about to have to endure a discussion at the Lead Developers desk no.

"Copying and pasting a few lines of code takes almost zero thought and no time"...and you're fucked. Pardon my French but it's warranted. Been there, done that, now know better.

Firstly software development is a thinky sport and the moment you're cut-n-pasting code while not thinking you're exhibiting risky behavior. Here come the bugs.

Guess what happens next: senior devs are busy, simple bugfix is assigned to junior or farmed out to contractor. They fix just one of the cut-n-pasted routines and call it a day. Then you play a few iterations of the PR to test failure game or you ship a bug. I see this all the time. I saw it yesterday. After it fails the tests enough and I get the PR I have them DRY that code up.

This is especially important if you've inherited a crappy code-base with lots of duplicate code. We have a rule that if you touch it you DRY it. Never had that rule not serve us well. Getting people outside the core team to stick to it is work, but that's a different oroblem.

API/framework complexity can often be minimized within reason, but given the code-template nature of pattern components it is unreasonable to expect optimization without incurring tightly coupled code/structures.

For example, a project using a framework may only require a developer look at 4 small files to understand the functionality of a resource, and it acts as inline documentation to others on how to quickly contribute new features. In a way, through explicit separation of resources the “similar” code tends to differentiate rather quickly as use-cases rarely share the exact same context throughout the entire life-cycle of a program.

The worst maintenance teams of popular projects permute an API definition every 6 months, and break existing production code in downstream works. You know, ironically still building that bug infested Ivory Tower everyone assumed they could avoid with grossly oversimplified acronyms ( https://en.wikipedia.org/wiki/Ivory_tower ). ;-)

No, it’s a pretty good principle, but just like everything in programming, there are no hard rules. Every principle has times when they are appropriate and when they aren’t and it’s our job to find what is most appropriate for the situation at hand. It’s still worth striving towards DRY, but that doesn’t mean that there aren’t many cases where it doesn’t improve the code.

The examples are also pretty contrived, there’s hardly any duplication there and the duplication is very simple and unlikely to change much. DRY is beneficial when the repeated code is complex and will likely need to be changed in the future (eg to fix bugs or to be extended), where repeating the code will be a source of error since every change would then need to be applied to each instance and forgetting one is a problem. The example is trivial enough that I wouldn’t bother refactoring it until it became complex enough to be a problem.

A good principle is to not apply principles too quickly/soon but only when not doing so would introduce complexity or cognitive overhead. YAGNI, basically.

As usual, when someone is trying to show how certain code idioms are bad (or good in some cases), the entire example is bad which makes it hard to even care about the entire point of the article.

As some have pointed out - make_pizza shouldn't be anywhere in the code. There should be a mongo collection or rel table that has a bunch of typical pizzas and a way to make custom ordered pizzas, typically through a UI.

The more complicated thing is the data structure that represents any pizza (like 50/50, 10/90, 10/80/10, toppings per section, etc...)

And a mongo collection for "typical" pizzas would fit that pretty well. And beyond that custom ordered pizzas.

All that being said even the above is over engineered. Typically this over-engineering is a result of allowing end-users to create a pizza. I'm super old school and still call in my orders on the phone. The difference being that end-user UIs that let you make a pizza need to be over-engineered while call in orders is just a bunch of notes and a total "additional toppings" count.

People forget that DRY means "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system".

The principle concerns the duplication of knowledge, not code.

Author's reference to "accidental duplication" is caused by two similar code that represents different code that is when joined becomes the code that is ambiguous in meaning.

There's no silver bullet. My opinion is that you should weight alternatives without repetition and with repetition and choose the most appropriate one. Also if in the future you feel that this common code is becoming more complex with options and switches, feel free to remove it by inlining, either completely or in a few places. Often it'll allow for better code or it'll allow to find out another way to extract common code.

Basically I like the refactoring approach. You have a set of refactorings. Like extract method / inline method. The point is that every refactoring is two-way. And both ways are useful in different situations.

To support this approach, sane IDE is a must and strictly typed language is preferable You should refactor your code without fear of breaking unrelated code.

What I definitely think is overrated is "if it works - don't touch it" principle. It's lazy and in the end it creates much more work than if one would gradually improve something that works.

Here's how I apply DRY.

As I build a thing, I just sling duplicate code like I'm getting paid by the line. Once I've created all or most instances of the duplicate code, and they're working, only then do I circle back refactor it to extract common concepts and abstractions.

I've learned over the years that I don't really understand what I'm building until it's built. I need to step back and look at the patterns that have formed to spot the difference between firm concepts and trivial duplication.

Doing this well takes experience. It involves predicting how your code is likely to change. One lesson from experience is to favor repetition over bad abstractions. I formed this opinion from living through the pain both types of anti-patterns. Duplication causes the need to find, change and test all instances. That sucks. It leave you open to bugs. But bad abstractions can require ripping the whole thing apart.

DRY absolutely can get this ugly and messy (I've seen it many times), but I believe that this is largely an experience problem. You have many tiers of DRY knowledge:

- Have heard of it and it sounds like a good idea

- Let's DRY everywhere!

- OK, maybe don't DRY everywhere...

- There are multiple ways to implement DRY, and it all depends on circumstance

Taking the article example, a better approach would be to DRY the data first (after discovering that in your organization the most common pizza is thin crust with tomato sauce and regular cheese):

    val STANDARD_PIZZA = {
        crust: "thin",
        sauce: "tomato",
        cheese: "regular",
    }

    val TOPPINGS_PEPPERONI = ["pepperoni"]
    val TOPPINGS_HAWAIIAN = ["pepperoni", "pineapple"]

    def make_pizza(design):
        requests.post(PIZZA_URL, design)

    def make_standard_pizza(toppings):
        make_pizza(STANDARD_PIZZA + {toppings: toppings})

Now it's easy to use with no repetition:

    make_standard_pizza(TOPPINGS_PEPPERONI)
    make_standard_pizza(TOPPINGS_HAWAIIAN)
    make_standard_pizza(["pepperoni", "ground beef", "olives", "feta cheese"])

You can easily add to it:

    val TOPPINGS_VEGETARIAN = ["green peppers", "tomato", "spinach"]

Then when you need to expand for half-and-half:

    def make_standard_half_and_half(left_toppings, right_toppings):
        make_pizza(STANDARD_PIZZA + {left_toppings: left_toppings, right_toppings: right_toppings})

    make_standard_half_and_half(TOPPINGS_HAWAIIAN, TOPPINGS_VEGETARIAN)

This gives you both low level and high level (convenience) interfaces to pizza generation, with none of the silly class complexity or function explosion.

He doesn't address the problem of in a large project, sometimes it's better to copy and paste a function to avoid the extra library dependency. DRY and over coupling are two forces that must be balanced by the engineer. Dry is more important at small scales, over coupling is more important at large scales.

Generally, I never think in terms of writing "DRY" code. I think the presumption of re-usability is a primary reason.

I architected a React.js framework that needed to exist in our existing portal environment and play well with all of the other frameworks and scripts. My solution was tightly coupling bundles of code for widgets deployed on my platform. I have conventions all devs need to follow and it does result in not very dry code.

The benefit is that everyone can work independently and not affect each other. Testing is easier to do as there are less logic paths. Performance is still optimized with code-splitting, so the extra code really doesn't affect performance.

Whenever people try to create a DRY one-size-fits-all solution, I find them very inflexible and prone to breaking. Add to that, they are generally poorly documented, so making changes can be very stressful.

It looks to me that the author has not faced a problem with DRY, but a junior developer and/or YOLO approach to architecture design.

In many cases thinking about possible future features/extension was one of the most limiting, complexing and at the end irrelevant approach out there, because it usually turned out that the future was different than it had been imagined. On the opposite side, when you take into account just what you know at the time of writing, led to easier adjusts, because it was way more clear to understand.

DRY is a great technique to organize your code, you just need to think about the structure first. In this article, the problem was that he wanted to bend 2 pizzas method into many other different types of pizzas, so his pizza architecture changed so vastly that it was not possible to describe it with just the initial idea of pizza.

I think you could make a decent case for DRY being the only principle.

If there's something getting in the way of DRY it's probably the biggest problem you have. However, that doesn't mean you have the ability or control to fix it completely in the short term, but the arc of history bends towards DRY I think.

In this specific article, the first example seems better the DRY way to me. The author seems to suggest that rewriting it later is worse than repeating the logic everywhere, which sounds very fragile. If you can't confidently rewrite an API later than you're doomed to repeat yourself until it all collapses. You could make a reasonable argument that the developer who fulfils the short term requirements and has found a new job by the time it all collapses would have a more lucrative career, but I doubt you could argue it's better software.

Only part of this I would quibble with:

> Copying and pasting a few lines of code takes almost zero thought and no time. Find and replace are very good at finding repeating things later if we start to care

Find-and-replace is unfortunately not really adequate for finding repeated code, in my experience. There must be much better tools out there.

The first code example doesn't make sense. There is no good reason to write code like that which hardcodes payloads for different types of pizza. It's a realm of data. Realistically, those payloads will either be constructed by user in the UI, or they will be provided in json file as predefined variants.

I actually think that the example provided in the article can be solved easy - without adding too much complexity with OOP as the author explains in the third point.

Yes, I actually think OOP is not bad :)

But I disagree with their conclusion:

That the goal is to send a post with a single JSON object and marking this task as:

> That is a very, very simple thing to do

That is a very simple thing to do if you think that you will write this code once and never have to change it to fit some new requirements.

But probably there will be changes either from your own business or because the API will change thus the task becomes:

<< How can I implement sending a post request that will follow a body request format and create a code that is simple to understand and _easy to change_ >>

And as right now when you write this code you cannot know what kind of change will come in the future the best way to move forward is to write small functions with very few conditions and open to extensions.

Thus repeating that code there is not a good solution. What if the API will request to add any new key in the payload? And those two methods (def make_hawaiian_pizza and make_pepperoni_pizza) are not in the same file and the one doing the implementation is not the current author to remember "ahh the code is duplicated so I have to change it in multiple places"?

Anyhow there are cases when duplication is good, but when composing the payload for a request is not one of them :) IMHO.

Let me add to think one more thought: the structure of code tends to be duplicated in the future. So choose not to DRY having in mind that people who will write code after you will tend to make the same choice. They will look at what you wrote and then follow a similar structure.

So don't DRY but make sure you do this in a place where you will be ok with other people increasing the number of duplicate code.

This post is not very good.

DRY is a really solid principle (pun intended.) If you have to define the payload schema for an API yourself (i.e. the API provider doesn't supply a library for you) then you really should define that in one and only one place. It doesn't matter thst today you only want a "handful" of hard coded JSON dicts. That path quickly leads to so many headaches and run time errors.

Implementing the API schema in one and only one place means you limit the sources of bugs for all code that deals with it. You only have to test that functionality in the one place it is defined, if it changes you don't jave to chase down hard coded JSON all over your codebase, etc

This post basically amounts to "I want to write lazy bad code and DRY tells me not to."

Write code that is easy to delete: https://programmingisterrible.com/post/139222674273/how-to-w...

If you have the same code copied to several places it makes it much harder to maintain. If there you find a bug in that code block then you have to fix it in several other places, and if you forget some, a bug that you thought you had already fixed might arise again.

I think DRY is one of the first pieces of advice that many programmers come across. Taking it to heart as a beginner it has the advantage of encouraging you to sometimes stop and give a bit more thought to what you are actually doing. Is this essentially the same as what I'm doing over there? How is it different? Why is it different? Etc...

As you gather experience you can recognise these patterns more easily and develop a stronger intuition for when you should pursue a DRY approach or just leave things as they are. You might even choose to make two things even more similar so that they feel more familiar (i.e. choosing to be even less DRY!)

Translation: I took DRY in isolation, never learned larger architectural concepts like SOLID, things that change together live together, loose coupling. Didn't really study up on code smells and their solutions. Didn't learn design patterns and the problems they are designed to solve. Then I ran into trouble and now I blame DRY.

The point of DRY is that when you need to change something, you should only have to change it once (a common code smell that comes about when not employing DRY is "Shotgun Surgery"). If the rest of your architecture is broken, DRY is not going to magically save it. That should be obvious.

Now. I am not a 10x developer.

But this concern here with writing a make_pizza() function:

> The problem is that these two pizzas just happen to have the same crust, sauce and cheese. Had we started out with two pizza types that have different crust/sauce/cheese, we never would have made this refactor.

You can solve for this by adding parameters with default values for all of those things. Use the defaults for the most common use cases, but of course for pizzas with different crusts and such, you can override the default.

Not all languages support default parameter values, it's true. And of course, there is a level of complexity at which this breaks down.

Like all principles, if you don't understand it, then you're going to misuse it, and then some people will wrongly blame it for being "over-rated" rather than blaming their own understanding of it.

My personal rule of thumb for this type of situation is to use the counting scheme “one, two, many” and to try to defer commonizing before you get to “many” instances of the repeating pattern.

It’s really easy to make assumptions about what you are going to need later that turn out to be completely unfounded (or even - years later there is no “many”, just the one or two usages you already have).

And I think folks shouldn’t freak out over a little bit of duplication, as long as it doesn’t get out of hand in the codebase, and you make sure to come back to refactor later when you do have many common usecases.

But wouldn't rejecting DRY (in a way) follow another over-rated programming principle called KISS? /s

In all fairness, the best programming principle is: just like with software licenses, know what to use and when.

I agree with the principle of this blogpost, though IMHO this was covered better and with better examples here: https://lbrito1.github.io/blog/2017/03/dont-obsess-over-code...

I also think the title of "don't obsess" covers the intent better. In other words, it's perfectly OK to write DRY code, but don't obsess over making all code DRY all the time at the expense of readability.

> Now we are talking about all kinds of fancy programming stuff to try to solve problems that only exist because we don't want to repeat the same 6 line snippet in a handful of different places because DRY tells us that's bad.

Introducing unnecessary complexity is, by definition, unnecessary. But we shouldn't be introducing complexity because DRY tells us. We should introduce complexity - some, but not more than needed - because some day a developer will know to update 2 of these 6 line snippets, but won't know about the third.

The best principle is KISS https://en.wikipedia.org/wiki/KISS_principle

> "Keep it simple, silly", "keep it short and simple", "keep it short and sweet", "keep it simple and straightforward", "keep it small and simple", "keep it simple, soldier", "keep it simple, sailor", or "keep it sweet and simple".

It's true that often, complexity is praised...

Do what's best for the situation, WET/DRY principles both have valid application use cases. They should be used to leverage the most advantageous effect for your usage.

I dunno, the only thing I came away with here is that the author either doesn’t know how to write decent code, or deliberately obfuscates the problem by writing obtuse stuff.

To help figure out when to DRY or leave wet i like to use the rule of 3. Where a piece of code needs to be repeated 3 times before it is DRYd up. You can adjust this number from 3 to whatever you would like.

What I really like about rule of 3, vs rule of 2, is that it allows more time to go by that may lead to the two pieces of code no longer being identical as requirements change. Which would either remove the need for the abstraction or allow for a more accurate abstraction.

Speaking from many painful experiences, DRY is underrated. Duplicate code is a major liability, and due to the natural entropy of code, duplicate sections will slowly drift apart over time.

Yes, sometimes you may discover that you prematurely DRY'ed the code, and it was just accidentally similar. Easy, you just un-DRY the code. This is a trivial operation. In an IDE it might be a single keyboard shortcut. Going the other way is a difficult and error prone process.

I'll claim the only universal truth in programming as in anything is: "moderation", and it's corollary, "there is no silver bullet". They are all rules of thumb, and knowing when to apply them is the most important aspect of rules.

In this case, unit tests are a very reasonable place to "repeat yourself", so you don't have to figure out what it's actually doing. Seeing the code all in place makes life easier.

DRY has the same idea as modules. Write once and re-use it.

This article is the result of someone exploring a new idea and cussing it out because he has to change his ways. I've been there countless times.

DRY is not overrated. DRY is a time saver in the long run. Why is this even on top of the 1st page, how new are you to development anyway?

Sorry but I'm really getting pissed off by people wasting my time with useless articles lately. It's getting out of hand.

Valid points, but it doesn't make DRY overrated. Just abused / taken too far if one is overeager. That's true of any principle if you're being dogmatic about it and start treating it as a goal in and of itself (rather than as means towards a goal). This, to me, fits the typical "X considered harmful" (headline) / "X considered harmful when done badly" (actual content) template.

I'm at most a 2x developer and?definitely have solutions in mind.

For one thing, pizza recipes are either dynamically built by the customer or they are just fixed recipes.

Having individual functions for different predefined pizzas is not really dry enough for me.

I would have a pizzas.yaml file, and a get_pizza_recipe("id"). Maybe I'd even read pizza data from an excel spreadsheet directly for ease of editing and sharing by management if needed.

It's worth knowing when it's useful to apply. Needlessly duplicating code also creates another kind of complexity: large surface areas of change that need to be updated in tandem. If you get changes where you have to change multiple places at once in the same way it's a good sign you need to do some refactoring before someone accidentally introduces an error into the program.

That's just justification for unnecessarily using microservices, which basically leads to 75% of your code being redundant plumbing. Microservices (correction: distributed systems) purposefully throw away DRY, small cohesive teams, developer ergonomics, and streamlined debugging, in favor of solving hard problems at scale, which most companies simply don't have.

DRY often leads to too much abstraction that while correct from the theory of software engineering, it increases complexity and maintainability costs.

That being said, I always allow myself to repeat code until a good enough patter emerges from that repetition, and then I refactor. Having the same code twice is not always sufficient to reveal what is the right refactor to do, if any.

The one and only important programming principle: use your brain.

Not every problem is the same and not every pattern could be used to solve every problem.

DRY requires some judgment

If you have two features that have N parts in common, and you are certain that they will never diverge for feature-specific customization or special cases, then DRY is probably a good idea

If they may diverge at some point, then structuring the code in anticipation of that divergence is a good idea, else you end up with a messy DRY implementation that inevitably has to fork

The key skill is to distinguish between harmful repetition, harmless repetition and beneficial repetition.

Say you have two templates (web pages). They are conceptually independent and serve two different business purposes. Yet in terms of their structure/content/whichever, they have about 20% in common.

Somebody obsessed with DRY would now elevate that 20% into some reusable module, after which both templates use it and the repetition is gone. Feels clean.

In reality, you didn't solve a real problem whilst you created a new one. Now individuals/teams cannot independently edit these templates as they need to understand and check the dependency tree. It no longer is simple, there's no piece of mind.

Next, inevitably somebody is going to request changes impacting that 20% and before you know it and after cutting lots of corners, you end up with this freak component that changes output based on some flag.

It's taken me 20 years to come to this conclusion: the negative effects of (too much) DRY (it increases complexity) show up in every single project and make code harder to understand and change. Meanwhile, the negative effects of allowing (some) repetition are mostly theoretical and more often than not a benefit, not a negative.

I mean it. This is coming from an ex-DRY fan boy. The DRY principle makes us eager to connect dots that really aren't connected and shouldn't be connected.

For an excellent code base to see DRY in action, look at tinygrad: https://github.com/geohot/tinygrad

I believe it has a potential to be a great alternative to pytorch.

I love watching GeoHot's Twitch streams as he goes to the extreme to simplify the codebase, and the end result is amazing.

If I’m not mistaken the original point of dry is to not repeat data/state, rather than not repeating code.

Being dry about state is actually really useful (essential!), where state can be derived it should be, rather than stored as a new variable. Being dry about code is often less useful in my day to day coding, but I’m not a library designer I just make apps /2c

Looks like a perfect case for a builder pattern, that way you can support sensible defaults in just about every language.

default_pizza() .with_crust(Crust::Cheesy) .with_sauce(Sauce::Garlic) .add_topping(Topping::ExtraCheese) .cook()

I'm not going to weigh in on the DRY stuff because it's being discussed to death. I just liked thinking about how I would approach this problem.

There's nothing wrong with DRY. It's a concept not a law. I once saw some VB6 code that was 30k lines of copy pasted if/then statements. DRY would have reduced this to about 500 lines of highly readable code. Are there cases where you by design don't want to follow DRY yea... There are... But it's not a useless principal

> It's also probably one of the simplest principles to understand.

Turn‘s out - no it isn‘t!

I think DRY and KISS are probably the most important and most misunderstood principles by far. Why? Because they seem trivial at first sight, but really are not.

Not every repetition should be DRYed (dry those which pose a risk to integrity) and „simple“ is not the same as „easy“ or „familiar“!

The problem with DRY is that it doesn't tell you how many repetition is too many.

Here's my advice: don't refactor when you repeat yourself twice, refactor when repeat yourself _three_ times.

Having one chance to copy-paste before DRY'ing your code has been one of my most treasured coding tricks, it'll save you so much time and premature refactoring.

"Sometimes duplicating things, either code or data, can significantly simplifies a system. DRY isn't absolute." - John Carmack

ref: https://twitter.com/id_aa_carmack/status/753745532619665408

DRY is mostly a good thing. What complicates stuff at companies is often coupling and dependencies though. Sometimes it is way faster and better to do a bit of copying just for the sake of removing coupling. This is largely due to the short comings of programming langs, packaging tools, CI/CD and source control.

> Having the meaning of the first argument change because you passed an optional second argument is very odd.

Is it, though?

And yes, I would totally just make it so the function detects whether I am passing in an object or an array of objects and respond accordingly.

I feel like I got this pattern from jQuery or something. Seems very normal for a good library.

No, the correct way is, write down some configuration, then with a little code to turn config into real pizza !

I think the underlying meta principle here is: Don't be dogmatic in your following of principles. Make sensible choices for the use case at hand which might be informed by the spirit of principles, but don't treat them like some biblical commandment that has to be applied at all time.

Misses the most important reason.

Repetition creates symmetrical cases. As they say in German, 'einmal ist keinmal' -- once is never. Overly DRY code is incredibly non-educational.

Why?

Because you learn by comparing and contrasting -- if you can't compare, you can't contrast, and therefore, you cannot learn.

One article advocating against unnecessary abstractions that I really appreciate and highly recommend is Dan Abramov's: https://overreacted.io/goodbye-clean-code/

To me, DRY, like Single Responsibility, is practical to a point, after which it doesn't support its weight. It strikes me as being similar to normalization in relational databases and summed up by "Normalize till it hurts, denormalize till it works".

> The problem is that these two pizzas just happen to have the same crust, sauce and cheese.

The problem with analogies is that they are often bad. Don't don't specify that you want tomato sauce and regular cheese when you order your pizza because that's the default.

New devs start with doing DRY everywhere. Over time they learn to be more thoughtful. Sometimes duplication is good. In my experience the priority should always be dev readability. If duplication helps you read the code better (as its not hidden away), thats fine.

On the other hand, I find most frameworks don't allow for DRY. The typical case is making a 40 char DB field, and then having to code a check in the payload to ensure field is 40 chars. I've wondered if any system has achieved such enlightenment.

I’ve had success with WET - write everything twice. If you copy paste something three times it’s a good candidate for abstraction. Ultimately these are just rules of thumb and none will fit all cases. I just found DRY to be too aggressive in practice.

Same thing without the clickbait title: https://ahungry.com/blog/2020-11-17-Write-Code-Like-You-Writ...

In UI work I prefer copy-paste when there is no clear abstraction. So far this has paid off.

For me, a good way to evaluate whether you should combine them is to ask this question: If I need to change it on one location, do I need to do the same on all the location? If yes then it's a good candidate to abstract the code.

One of the dumbest blog posts I've ever read. Who is upvoting this stuff? If anything I see newer devs _not_ embracing DRY. Some of the codebases I've seen lately are hilariously bad, especially in frontend development.

Guy got upset during a code review and wrote a blog post about how he's right.

At our first start up, we always used to say "RY before you DRY", so: you have to repeat yourself first, consciously, before you can start with abstractions, because bad abstractions are worse than no abstraction

I think Kent C. Dodds gets to the goal behind the DRY principle fairly well here:

https://kentcdodds.com/blog/aha-programming

I tend to start DRYing up my code after five usages. I think it's a balance that has kept me away from the unnecessary complexity, although the Gateway drug is real- I catch myself wanting to DRY early now and then

A simple lesson on functional intent, variants and invariants, doesn’t need to be some overarching development management principle like DRY. Let’s just teach people how to write clean, readable, loosely-coupled code.

I view strict DRY (and only DRY) adherence asa sign of less experienced devs. I was like this in my early days, almost religiously following this creating wrong abstractions. Thanks a lot for those examples.

Premature generalisation is the second cousin of all evil.

The problem with DRY is that the cost of it being wrong in the future often isn’t accounted for.

Copy, paste, search, replace is underrated.

That said, it’s a balancing act. The right generalisations are great.

Ironically, the second example has a copy-and-paste bug:

  def make_pepperoni_pizza():
      make_pizza(["pepperoni"])
  
  def make_hawaiian_pizza():
      make_pizza(["pepperoni"])

Sometimes having repeated sections makes it easier to understand the code, and later figure out how to merge the logic to remove them.

Separating it out into a function can obfuscate things making it harder to do that.

I had a general guidelines in my previous company which I follow to this day to great results.

If a piece of code is duplicated thrice, it's ok. If a piece code is duplicated four times, then you must extract it.

I must say, that mediocre article lead to very interesting comments.

Might be worth it to redo the examples here in Lisp (with and without point free) and see what happens.

Partial application might make the first example a little less ridiculous, for instance.

This article is fine, though the headline is misleading. In the end, the author still seems to believe that DRY should be the rule, not the exception, and I agree with that.

When I hear “DRY”, I think of Django with its Models, ModelForms, etc., not enterprise Java where every piece of functionality is hidden behind 15 levels of indirection.

A little copying is better than a little dependency - Rob Pike

DRY code is a good value, but it is not an all important value. It's one of many values, and must be kept in balance.

It's not the end-all, be-all but it is a generally good principle.

But yeah, 100% dry code that is also practical to maintain is also a fucking myth and not grounded in reality.

DRY is better for performance (cache efficiency). It’s also less work for the compiler. Those might not be concerns of someone writing pizza CRUD in python.

This article is just a rant against what the author sees as popular-but-wrong justifications for DRY, while failing to mention any of the good reasons. -1

Here is my take: if you run your code through gzip (or similar) and it gets any smaller, you've repeated yourself somewhere.

I'd rather read the gunzipped code.

Surely I'm not the only one to notice the first example refactoring is wrong, in a strangely ironic fashion too...(but too lazy to contact author)

Uhhhh... Anyone who says DRY is overrated has never worked on someone else's codebase that didn't follow attempt to reduce repetition.

What a waste of a click.

I prefer YAGNI.

http://c2.com/xp/YouArentGonnaNeedIt.html

I feel like most of these articles would lose their click bait appeal if the title always included "when done wrong" at the end.

What does everyone think about this argument for functional languages especially with regards to parametricity in languages like Haskell?

Two is company. Three is a crowd.

If code is duplicated twice, I'm ok with that. If it's duplicated three times, then it's time to refactor.

Just set intelligent defaults with the ability to override with customizations. Bam. It's DRY and you don't lose flexibility.

DRY is mostly fine in code, but does not hold for data. There, inmutability and audit trails win over DRY, in my opinion.

The only programming principle you should be using is getting things done as fast as possible and shipping to production.

The "single responsibility principle" has caused a lot of damage as well. SOLID in general is somewhat dubious.

I like DRY. Do Repeat Yourself. You can always refactor later, once the requirement/change is fully implemented.

The problem with dry is no one tells when when to not use it. It's great when you have 5 instances of the same string, much like oop is great when all your objects are animals that fit into a neat little category. It's not so great when you're drying code across feature boundaries. Features tend to diverge over time rather than converge so what's dry one day is garbage the next. You refactor the code to be dry so 3 features are now one function and someone comes along asking for an amendment to one of those 3 features which adds an edge case to your function. Now you've broken another feature because you didnt check if your new edge case would change other features but quality control didn't check the other features cause no one asked for that feature to be changed and how do they know that it's all one function under the hood. Now you have bugs in production and no one to cover your ass. Time goes on and you add more edge cases and now you have one function that does many things with special edge cases throughput it. You cant separate one feature without interacting with another, almost like you're interacting with strands of spagetti and you can't help but pick up a bunch when you only really wanted one noodle.

Tldr if you're making code dry and you insist that you make code dry across feature boundaries then for the love of god make unit tests for those functions. Or keep your functions dry and your features wet.

> DRY creates a presumption of reusability

I stopped reading there. DRY creates maintainability, not necessarily reusability.

I fondly remember the Ember.js docs.

They were awesome, but all the code examples where DRY to the max, it was quite funny.

TL/DR: It's a naive "sour grapes" type argument that doesn't take any kind of costs/tradeoffs into consideration...

Proper DRY at scale requires types that make sense and are easy to think about (you have to invent and document them even in dynamic langs ...that's why Typescript's a thing and so sucessful). You can't have DRY that doesn't slow you down and cause bugs without proper f types!

Eg. a sane solution to the authors' problem when the requirement for split pizza came would be:

- rename make_pizza(toppings: dict) to make_pizza_part(topings: dict)

- implement a new make_pizza(topping: list[dict]) calling make_pizza_part(toppings: dict) - and here you've change the type (important!), so you'll not miss any unchanged all calls to it, your tools will yell at you (ideally at build/compile/commit), or at worst at runtime but with an easy to interpret even from logs error

DRY is fine if done in the context of proper software engineering practices and tools.

Now being non-sloppy and following solid practices has a cost, and you might want to avoid it sometimes - in those cases do less DRY rather than crappy DRY!

(Whole languages are built around the OP's philosophy, eg. Go, but they are explicitly engineered to lower cost and defects in large corporate orgs! Randomly choosing to follow this in a project with 1-3 people of adequate skills and limited scope will just unnecessarily make that project have 4x the code, 4x the bugs, and 4x the cost for zero benefit.)

You should have called the blog post "DRY considered harmful" and go down in history.

I'd argue that over using inheritance has more dire effects than going full hog on dry.

DRY is about readability. If DRY makes the system more readable, do it. If not, don't.

DRY is about readability. If it makes the system more readable, DRY. If not, don't.

Reading the code I get a feeling author doesn't quite know how to write code.

,,To solve my sauce issue, maybe I could use an OOP style and have a PizzaOrderer class that can be subclassed for each pizza type, allowing each type to override sensible sauce/crust defaults.''

No, DRY doesn't mean that you should create classes just to prove your (invalid) point.

just treat things as suggestions. stop turning things into unmovable laws. dry - if you are constantly writing the 90% of something multiple times, maybe look to see if you can genericitize it.

I have wondered if we sometimes sacrifice readability for DRY.

there isn't a one-size-fit-all DRY. If there's much gain by DRY, then refactor it with a factory or something. Otherwise, keep it intuitive and stupid.

Not as overrated as this discussion is bike shedding.

By the title alone I would have to say I disagree

Tl;dr with the comments but I didn’t see “debugging” or “maintenance” showing up. Collecting things, which I assume is an aspect of DRY, makes it less risky - the change or fix can be applied once rather than hoping all of the instances in the code were addressed (correctly). Developer time is precious no matter how many of them you have. Given a sensible design, you can always tune hotspots. Can’t speed up debugging and brittle or unclear code means you’ll be doing more of it.

And if it’s “just going to be used once” who really care how it’s written other then “quickly and correctly”? And sadly, too many things aren’t just used once.

All things in porportion

Pizza Cost Optimization Dark Pattern Programming Example:

Here is the pizza cost optimizer from Pizzatool, written in object oriented NeWS PostScript, which checks all of the pre-defined base pizza styles and selects the "best" combination of style + extra toppings, ostensibly to save the user some money.

It's actually a dark pattern, because it's biased towards selecting higher level pizzas instead of the least expensive pizza. But at least the dark pattern is documented:

"Figure out the cost of the pizza, were we to order it as this style, and remember the style as the best match if it pleases us. The definition of pleasing us is biased towards matching higher level complex pizza styles, rather than economical lower level pizzas with extra toppings. This is the kick-back to Tony&Alba's for all that free beer."

The Story of Sun Microsystems PizzaTool How I accidentally ordered my first pizza over the internet:

https://medium.com/@donhopkins/the-story-of-sun-microsystems...

Tony and Alba's Pizza and Pasta, Mountain View:

https://www.yelp.com/biz/tony-and-albas-pizza-and-pasta-moun...

PizzaTool Source Code:

https://www.donhopkins.com/home/archive/NeWS/pizzatool.txt

    % Calculate the cost of this pizza.
    %
    /updatecost { % - => -
      10 dict begin % localdict
        /TheBest /defaultstyle ClassStyle send def
        /TheStyle null def
        /TheTopping null def
        /TheBestCost 99 def
        /TheBestExtras 0 def

        % For each and every pizza style in the universe:
        /styles ClassStyle send { % forall:               % style
          /TheStyle exch def                              %

          % Ask this style for its list of standard toppings.
          /TheToppings /toppings TheStyle send def

          % Is every topping from this style on our pizza?
          true                                            % true
          TheToppings { % forall:                         % true topping
            Toppings exch arraycontains? not { % if:      % true
              % Oops, this topping's not on the pizza. No dice.
              pop false exit                              % false
            } if                                          % true
          } forall                                        % true|false

          { % if: all the toppings of the style were on our pizza:
                                                          %
            % Make an array of our pizza toppings that aren't in the style.
            /ExtraToppings [
              Toppings {                                  % ... topping
                % Is this topping included in the style? Then toss it.
                TheToppings 1 index arraycontains? {      % ... topping
                  pop                                     % ...
                } if
              } forall
            ] store                                       %

            % Figure out the cost of the pizza,
            % were we to order it as this style,
            % and remember the style as the best match if it pleases us.
            % The definition of pleasing us is biased towards matching
            % higher level complex pizza styles, rather than economical
            % lower level pizzas with extra toppings.
            % This is the kick-back to Tony&Alba's for all that free beer. 
            PizzaSize /pizzasizeindex self send           % sizeindex
            ExtraToppings length                          % sizeindex extras
            /extraprice TheStyle send                     % $
            dup                                           % $ $
            ExtraToppings length                          % $ extras
            /extras TheStyle send sub                     % $ $ extras'
            1 le { .9 mul } if                            % $ biased$
            TheBestCost le { % ifelse:                    % $
              % Hey this is the best match so far, let's not forget it!
              /TheBestCost exch store                     %
              /TheBest TheStyle store
              /TheBestExtras
                ExtraToppings length /extras TheBest send sub
              store
            } { pop } ifelse                              %
          } if                                            %
        } forall                                          %

        % Set the window footers of the pizza topping panel.
        % The left footer displays the name of the pizza style,
        % and the right footer displays a message
        % telling the user to choose more toppings,
        % or the number of extra toppings,
        % or nothing at all.
        TheBestExtras dup 0 lt { % ifelse:                % extras
          neg dup 1 eq { () } { (s) } ifelse              % extras (plural?)
          exch (Choose % more topping%!) sprintf          % (message)
        } { % else:                                       % extras
          dup 0 ne { % ifelse:
            dup 1 eq { () } { (s) } ifelse                % extras (plural?)
            exch (With % extra topping%.) sprintf         % (message)
          } { % else:                                     % extras
            pop nullstring                                % ()
          } ifelse
        } ifelse                                          % (left footer)
        /name TheBest send exch                           % (left) (right)
        /setfooter ToppingWindow send                     %

        % Remember the price of this pizza in dollars rounded to cents,
        % and calculate its string value. 
        TheBestCost                                       % $
        Fraction mul
        100 mul round 100 div
        /Price 1 index store
        dup 100 mul round cvi 100 mod                     % $ cents
        exch floor cvi                                    % cents dollars
        1 index 10 lt { (%.0%) } { (%.%) } ifelse         % cents dollars fmt
        sprintf                                           % (price)

        % Set the value of the costfield and totalfield labels to
        % the price string.
        dup /setvalue costfield send
        /setvalue totalfield send                         %

        % Set the value of the stylevalue label to the name of the best style,
        % and set the stylemenu value to the index of that name in the list of
        % pizza styles. (The stylemenu is an exclusive settings menu.)
        /name TheBest send                                % name
        dup /setvalue stylevalue send
        PizzaStyleNames exch arrayindex {                 % index
            [exch] /setvalue stylemenu send               %
        } if                                              %

        % Remember the best match pizza style.
        /Style TheBest store

      end % localdict
    } def

what about early returns?

WRONG. OOP is the most over rated

just build it

The DRY example is better though. The payload is an object. When you have multiple objects of the same shape you have a class of objects. Menu items could be loaded from a JSON source. Separation of concerns and duplication is removed from the code.

I wouldn't recommend naming your function with a suffix that relates to a model. You are better off doing:

def generate_payload(crust, sauce, cheese, toppings):