Live data from Hacker News

DRY is an over-rated programming principle?

gordonc.bearblog.dev

201–210 of 501 posts

Re: DRY is an over-rated programming principle?

#201
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…

The article is claiming that slavish devotion to DRY results in issues. You are giving names to the issues resulting and calling the article bad.

Re: DRY is an over-rated programming principle?

#202
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…

I like this. It is very hard to find out if the definition already exists or not in the codebase. This can lead to multiple definitions of the same thing or the truth. anyone has a good way to deal with this?

If the codebase isn’t a total mess, one should be able to guess which components or code paths have to deal with a given truth by virtue of their purpose/function. Then one can investigate the code paths in question to find out where exactly the existing code is dealing with the respective thing.

It should be an automatic thought when implementing some logic to think about which other parts of the system need to be consistent with that logic, and then try to couple them in a way that will prevent them from inadvertently diverging and becoming inconsistent in the future.

In terms of software design, a more general way to think about this is that stuff that (necessarily) changes together (is strongly coupled) should be placed together (have high cohesion).

Re: DRY is an over-rated programming principle?

#203
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…

I like this. It is very hard to find out if the definition already exists or not in the codebase. This can lead to multiple definitions of the same thing or the truth. anyone has a good way to deal with this?

Unfortunately the issue of lacking a single point of truth is exacerbated the more people who work on a project. I believe the issue in spreading around logic comes from not knowing the original intention, and asking the original authors is, IMO, the best way to fix something or add new features. Obviously knowing the original authors is not always possible, so I try to follow existing patterns.

Re: DRY is an over-rated programming principle?

#205

Earlier quoted context omitted.

While one can certainly over-engineer everything into N levels of abstraction either with OOP stuff or with FP stuff like higher-order functions (or higher-higher-...-order functions for that matter), I could well imagine, that a person who knows FP stuff would not have as much of a problem with a specific code base and when that person leaves and only OOP-only people are left, they scratch their heads and call it an…

Honestly, I'm done trying to flip the script and approach it as a "well maybe they truly need smarter people to read the code". Companies are openly looking for people giving them a spoonfed answer on 'good code concepts'. Most of these concepts have no academic basis, can be argued rationally both for and against, are shown to be damaging on a daily basis, and seem to have nothing going for them but 'preference' and…

In my mind a fitting analogy to building software is like designing and building a machine or a physical tool in mechanical engineering: like a CNC machine, a laser cutter with an optical system for processing etc.

There are no rules in designing a machine except for: These are the requirements. First drafts will be analyzed and iterated on by simulation and prototyping (e.g. for mechanical resonances, thermal deformation) - an inexperienced engineering team will have to do a lot of testing and prototyping and failing, while a team who has some experience in building a machine in a specific domain will know what to look out for and what can be compromised on.

There are best practices but I feel they are always domain-specific (e.g. everyone wants to put their precise machine on a big block of mass to isolate it from the environment on a machine in a shop floor, while the best-practice for a similar application working on a plane is totally different).

Re: DRY is an over-rated programming principle?

#206

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…

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.

Re: DRY is an over-rated programming principle?

#207

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…

> 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. Next day "I don't trust loops, these need to be unlooped". Really? This was all in writing and stated out loud in a meeting with witnesses, and everyone agreed. "Loops can be tricky - they don't always work like you think" (something like that). So a 30 line block of code with a loop around it became 1200+ lines with 'v1, v2, v3.... v50', with 'ifs' around each one to check if that row number was also submitted.

The code to generate the form was, of course, a loop that spat out holders for 50 rows. THAT was OK, because someone else's team wrote that a while back (really??) and ... it was already done and in production. The lead could not put their stamp on it.

Very very very weird. Having half a dozen other people all nod their head suggesting that a 30 line loop is fraught with danger, and the correct answer is copy/paste 50 times. Felt like gaslighting, to my recollection. Worked in same dept, just not on same project together, but enough of this was heard/pickedup across the dept.

And... my colleague and I aren't there any more, and to my knowledge, that team lead is still there.

Re: DRY is an over-rated programming principle?

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

Re: DRY is an over-rated programming principle?

#209
post #146
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…

Even better IMO (although devolving into pseudo code): pizza_base = { crust: "thin", sauce: "tomato", cheese: "regular", toppings: [] } hawaiian_pizza = pizza_base { toppings: ["ham", "pineapple"] } pepperoni_pizza = pizza_base { toppings: ["pepperoni"] } def make_pizza(pizza): requests.post(PIZZA_URL, pizza)

Don't do this! OP's version is better!

It might be "fine", but you don't gain anything here while introducing both indirection and coupling. DRY is _not_ about data repetition. Data repetition is fine.

Alice and Bob having the same birthday is coincidental. And even if they are actually twins, you rather say that they are twins separately.

In your example you are just preserving keystrokes, but you don't say anything of value with 'pizza_base'. You haven't shown that 'pizza_base' is worth keeping track of or even mentioning.

A pepperoni_pizza with thick crust or extra cheese is still a pepperoni_pizza. A hawaiian_pizza's sauce being tomato doesn't relate to a pepperoni_pizza's sauce.

When coding data, just be explicit, verbose and keep it simple. Our text editors, IDEs and database APIs have affordances to change data in bulk. Those things are orders of magnitude easier if your data is simple, dumb and not complected.

Re: DRY is an over-rated programming principle?

#210
> 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“!

Post reply on HN