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

271–280 of 501 posts

Re: DRY is an over-rated programming principle?

#271

Post by gwbas1c »

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

Re: DRY is an over-rated programming principle?

#272

Post by [deleted] »

codesnik wrote: post #206
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…

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.

[deleted]

Re: DRY is an over-rated programming principle?

#273

Post by amw-zero »

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.

Re: DRY is an over-rated programming principle?

#274

Post by runeb »

wizofaus wrote: post #264
runeb wrote: post #232

Earlier quoted context omitted.

You could consider codegen from the single point of truth. Not always practical, but great when its set up with good ergonomics.

Codegen is great for lots of sync between client and server (I just wish there were more standardized tools), but what if it's a complex algorithm that you need to be able to perform both client and server side, assuming they use different languages?

That's where you need to consider practicality, and it degrades quickly. If it's fairly simple and compartmentalised code without external dependencies like services running on server, you could consider transpiling to target runtimes. But most likely at that stage you'll call a remote function through an API when you need that business logic on the client.

Re: DRY is an over-rated programming principle?

#275

Post by waynesonfire »

12thwonder wrote: post #194
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…

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?

It's interesting to note that this principal doesn't just need to apply at a low level, e.g. code. It continues to add value when designing application architecture. Or, can be used to help refine features.

Re: DRY is an over-rated programming principle?

#276

Post by layer8 »

lowercased wrote: post #207
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…

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

> my colleague and I aren't there any more

The only right choice in that situation.

Re: DRY is an over-rated programming principle?

#277

Post by throwaway787544 »

linguistics__ wrote: post #12
koshergweilo wrote: post #5

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

For those wondering, it's a reference to this beauty: https://i.kym-cdn.com/photos/images/facebook/000/838/967/e39...

thank you

Re: DRY is an over-rated programming principle?

#278

Post by scambier »

codesnik wrote: post #206
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…

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.

Re: DRY is an over-rated programming principle?

#279

Post by wazoox »

lowercased wrote: post #207
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…

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

Re: DRY is an over-rated programming principle?

#280

Post by ahallock »

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…

I've experienced this first-hand in a Rails app, last week in fact. The result was a messy, hard-to-understand hierarchy of classes and abstractions--just because two workflows shared some similarities. Usually I find this happening with hardcore OO programmers or bored programmers who feel the need to start creating and don't know when to stop. I prefer boring code at this stage in my career.
Post reply on HN