Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DRY is an over-rated programming principle?

gordonc.bearblog.dev

Post reply on HN
Print view View original

291–300 of 501 posts

Re: DRY is an over-rated programming principle?

#291

Post by ravenstine »

mavu wrote: post #13

> 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 act…

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

Sure, I agree, except DRY is probably the second greatest gateway drug to overcomplicating things to OOP. Actually, they really hand-in-hand since OOP features are often used to DRY things.

DRY can easily go too far because fundamentally it's about centralizing ideas with the premise that different operations can and should share units, even though a "writeSomeFileToDisk" function doesn't necessarily have to do the exact same thing between different higher-level operations. Because so many engineers emphasize "elegance", if a set of functions seem similar enough, they pressure themselves to write code that is shareable, hence more abstract. Abstractions are inherently more complicated and hard to understand, not the other way around. Rather than having very simple "molecules" of code that can be understood on their own, there is instead a much larger molecule of nodes that are connected by abstract dependencies, and those nodes may only have dependencies in common.

DRY should be done sensibly, but teaching DRY is a problem in our industry because we don't teach engineering discipline. We teach principles like DRY and OOP, and even YAGNI as if they are tenets of a religion.

Re: DRY is an over-rated programming principle?

#292

Post by thrown_22 »

strken wrote: post #97

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 elsew…

Not to mention it lets you do things like:

    mixed_pizza = {
        crust: [["thin"], ["thick"]],
        sauce: [["tomato"]],
        cheese: [["regular"]],
        toppings: [["beef"], ["pineapple", "pepperoni"]]
    }
Where you offload the logic of making multi-topping pizzas into the data.

Re: DRY is an over-rated programming principle?

#293

Post by jkingsbery »

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

Re: DRY is an over-rated programming principle?

#296

Post by michaelcampbell »

nevinera wrote: post #242
captainmuon wrote: post #190

Every time I read an article like this, "why 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 so…

In rails shops, "dry" is _always_ overused. It was part of the red->green cycle in TDD culture, and got mentioned in every context, and as a result nearly all legacy rails apps are filled with weird abstractions introduced in a commit with a message like "dry it up". The problem is that it's phrased as a rule rather than a smell. DRY deserves to be listed with other code smells that may indicate a missing abstraction…

Thanks; this is about what I was going to say but you said it better.

DRY is a tool, not a design goal. I think part of the Rails issue is a combination of the early Rails hype/philosophy, and the fact that DRY as a concept is so easy to "get", that everyone gets it but often fail the next step of "why". Without the why, you often can't figure out the right when/where so it gets applied everywhere.

It feels to me like another oblique angle of Goodhart's Law; eg: "A rule of thumb that becomes a required practice ceases to be a good rule of thumb".

Re: DRY is an over-rated programming principle?

#297

Post by bluejekyll »

tpoacher wrote: post #221
layer8 wrote: post #188

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 jus…

Occasionally, it's not clear if a single point of truth is entirely appropriate, or even if it is it can lead to tiresome extra levels of abstraction. In this case, I sometimes prefer a slightly different approach; let's call it CRAP - Cross Reference Against Protocol: instead of definitions effectively referring physically to the same point of truth, they are designed instead such that they simply cross reference ag…

The CRAP that you’re referring to is really only solving for a very minor downside of SPOT (and DRY), and that’s the inconvenient connection of technically unrelated code. In my own experience it’s far simpler to disconnect two code paths (copy a function, change its signature, etc) than it is to connect them to achieve SPOT.

In your CRAP model it seems like you’d be relying on tests or assertions to verify the “protocol”, if I’m understanding that correctly. Which means finding all the places where something needs to be true and then testing for it. Seems like a lot of work and wouldn’t necessarily catch all those places.

Re: DRY is an over-rated programming principle?

#299

Post by michaelcampbell »

scambier wrote: post #278
codesnik wrote: post #206

Earlier quoted context omitted.

I sometimes use term "mid-level engineer syndrome", for "too many levels of abstraction in the codebase". It is very common in my experience. And untangling it's usually harder then extracting common stuff from "dumb" code. I usually don't DRY things up until three repetitions. And in test code - try to not DRY at all, copypaste is a friend of readable and mantainable specs.

I have colleagues that take DRY to an extreme when it comes to tests. There are so many levels of abstractions that it's incomprehensible. Tests should be clear and readable, you shouldn't have to dig code to understand _what_ a test is doing.

Tests in particular SHOULDN'T be DRY, IMO. They need to be very much independently modifiable quickly; they're meant to be quirky end-runs around your bespoke, artisinal architecture to get at all the interesting bits. Repetition there is fine.

Re: DRY is an over-rated programming principle?

#300

Post by an9n »

wazoox wrote: post #279
lowercased wrote: post #207

Earlier quoted context omitted.

> 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. Had a colleague work under a 'team lead'. Needed to take a form with variable amount of rows of input data - max 50 - and take data, parse it, and store it. Took 20-30 lines of code. Nex…

Looks like straight out of https://thedailywtf.com/

It's been a while since I'd visited! Always amusing.
Post reply on HN