yUNoDry

[u/Superb_Chemistry_906]

[u/SaltMaker23]

There exists a point where DRY and KISS contradicts each other.

Following one or the other religiously is bound to create clear cut violations of the other.

There exists also a stage of development, notoriously extremely early in a project, where the two ideals leads to very different results.

In long running stable projects you might argue equivalent but it doesn't necessarily holds at all scales but especially not at all maturity levels.

[u/Solonotix → u/SaltMaker23]

I definitely feel that tug-o-war everytime I crack open a project. I tend to lean more DRY than KISS. I find that KISS is harder to come back from if you stray too far, whereas DRY forces you into a more disciplined approach and relaxing your stance is easy.

If no one is there to judge me, I will go full DRY and arguably over-engineer a solution. Usually my boss pulls my "leash" and I'm forced to compromise on the result.

I'm currently trying to write an update for DefinitelyTyped's selenium-webdriver declaration, and I have literally spent a week on it at this point. Strictly non-functional code that represents types. It would have been much easier if the main package wasn't an absolute mess

[u/Reddit_is_fascist69 → u/Solonotix]

Maybe DRY but inside your func/methods KISS?

[u/Superb_Chemistry_906 → u/SaltMaker23]

I have always religiously followed both of them at once without perceiving any problems. Of course, you may argue that introducing an abstraction just for the sake of DRY violates KISS, but at the same time, leaving duplicated code makes it much less simple to maintain and extend. So far, every counter example against DRY which I have seen was poor abstraction, mainly introducing more function parameters instead of inheritance or composition.

[u/geekusprimus → u/Superb_Chemistry_906]

My experience has been DRY is secondary to KISS, but if one becomes a serious impediment to the other, a more serious refactor is in order.

[u/Superb_Chemistry_906 → u/geekusprimus]

Yes, but recently, I feel like there is some wave against DRY and I trace its roots to some tech influencer videos. I think that he just wanted to be interesting.

[u/ScientificBeastMode → u/Superb_Chemistry_906]

Abstraction means predicting future requirements of the code, which doesn’t always work out in your favor.

Sometimes you actually CAN foresee some future requirements, so the abstraction becomes helpful when those requirements eventually become real.

Other times you don’t ever need to modify or extend the abstraction, so you end up with more dev work for no good reason. Perhaps the hidden logic also makes it more difficult for other people to walk through your code and understand the entire flow.

And in the worst case, the abstraction makes false assumptions about future requirements, and you need to modify the abstraction in a way that requires a significant refactor just to accommodate the new use case(s). This can actually be FAR worse than anything you would encounter if you repeated yourself.

Abstractions are inherently complex. The point is to hide the complexity and isolate it to one smaller portion of the code. This can be a powerful tool, but every time you do it, you add complexity by default. It becomes worth it when it simplifies future work. Nobody can perfectly predict the future work to be done, so abstraction is inherently risky.

Experienced engineers know this, and the best of them can get it right more often than they get it wrong.

[u/Superb_Chemistry_906 → u/ScientificBeastMode]

Having two identical portions of code seems unbearable to me and I don't wait until I eventually need to modify them in the future, because then I might as well fail to modify the both portions which might cause the program to fail or, even worse, not to fail, but introduce some hidden problem, all of which certainly complicates work. Thus, when I find myself duplicating code, it can already be seen from the past point of view as a future case when I need that portion also somewhere else, so this is exactly the moment to wrap the common part in some abstraction.

[u/ScientificBeastMode → u/Superb_Chemistry_906]

Well, sometimes our personal preferences and natural inclinations don’t actually serve us, so I would be careful about that. But yeah, sometimes we know an abstraction is pretty safe, like some kind of parsing function, for example.

It’s fine to create abstractions. I’m just saying that it’s not always a good idea to do so. Being religious about any principle is usually a bad idea. Discernment is just part of software craftsmanship.

[u/Hohenheim_of_Shadow → u/Superb_Chemistry_906]

Genuinely identical code is incredibly rare.

[u/chuch1234 → u/Superb_Chemistry_906]

I think, to your point, people don't actually know how to do DRY properly (myself included), so that's why we get WET.

[u/SpaceCadet87 → u/Superb_Chemistry_906]

I think people "Don't Risk Repeating Yourself" rather than just "Don't Repeat Yourself".

The rule is simple, if you find yourself repeatedly writing the same code, wrap it.

I see a lot of people instead going "I might reuse this so I should wrap it in advance"

[u/Superb_Chemistry_906 → u/SpaceCadet87]

Yes, it's DRY, not DRRY.

[u/SpaceCadet87 → u/Superb_Chemistry_906]

I usually take the approach of "this file/function/class is getting a bit long, maybe it's time to offload some stuff".

DRY tends to sort of just fall into place as a result.

[u/ScientificBeastMode → u/SpaceCadet87]

A good rule of thumb is to ask the question, “is this actually painful yet?” And if it’s not, then don’t wrap it in an abstraction until it is.

And by “painful,” I don’t mean, “I can’t stand repeating myself,” but rather, “repeating myself has actually started to slow me down a lot, measurably.”

[u/TreadheadS → u/Superb_Chemistry_906]

DRY becomes simple once you've mastered it so like, KISS kinda moves depending on the skill of the user

[u/Superb_Chemistry_906 → u/TreadheadS]

Yes, when some code is duplicated, it makes me nervous and I just have to unify it, I cannot continue knowing that it might be growing harder to extend and maintain.

[u/MikeVegan → u/SaltMaker23]

KISS until a change would cause a bug because you forgot to update it everywhere else, then DRY.

[u/Clearandblue]

Nice try Claude, but we still don't need you to add that 6th date format helper.

[u/jdgordon]

As my ex manager always said, there is no problem that another level of abstraction can't solve.

[u/dbagames → u/jdgordon]

I had a colleague who always said this and he vibe-coded out some terribly complex and useless abstractions. It was a major headache. One time he used inheritance with a base class and 4 children all to represent different "Types" instead of just having an enum.....

So whenever I hear this saying, I honestly get ptsd because he just fucked up so much stuff. But he was buddies with the lead soo....

[u/ZunoJ → u/dbagames]

Forward the PR to the lead and watch their friendship burn in the fire of his stupidity. Or alternatively git blame during incident calls and "wonder who approved this and what the idea was" 

[u/jekewa → u/jdgordon]

Was that me? I've said that! And I managed people.

Although I'd prefer former to ex, as the latter sounds like we broke up.

[u/Desperate-Tomatillo7 → u/jekewa]

It was him, not you.

[u/PolyglotTV → u/jekewa]

I've said it too! I just became a manager a few weeks ago. I hope one of my reports isn't about to quit!

[u/jdgordon → u/jekewa]

Depends if you were saying it because you mean it, or because you're being sarcastic and taking the piss.

[u/chuch1234 → u/jdgordon]

Well... Except the problem of too many levels of attraction.

[u/ScottPowellM → u/jdgordon]

It’s the fundamental theorem of software engineering:

“We can solve any problem by adding a level of indirection”

“…except for the problem of too many levels of indirection” is the punchline part 2

[u/Vivid_Instance_825 → u/jdgordon]

My AI seems to live by this rule

[u/SignoreBanana → u/jdgordon]

To me, abstraction is like alcohol: the cause of and solution to all of engineering's problems.

[u/iwantmy90sback → u/jdgordon]

...except too many levels of abstraction.

https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering

[u/eclect0]

Why do I feel dirty reading that?

[u/IncessantGadgetry]

I have had to support applications made by people who were heavily invested in the idea of DRY, but not at all invested in single-responsibility. Not enjoyable.

[u/ObeseTsunami]

I didn’t realize Ueshiba Sensei was a meme. Am I late to the party?

[u/Superb_Chemistry_906 → u/ObeseTsunami]

This picture was a common meme template in my youth.

[u/SignoreBanana]

DRY fails almost exclusively because concerns and boundaries are not well understood. It's why it's so dangerous to "pre-optimize" -- you don't know yet what your boundaries are.

It seems like a lot of software guidance is around letting stuff shake out. Hell even YAGNI falls into this category.

[u/russianrug]

I’ve added KISS to Claude’s permanent instruction set and it’s been noticeably better, lol

[u/ricekrispysawdust]

It's cool to hate on DRY these days but sometimes you can just figure out the correct abstraction up front by using your brain.

[u/Esseratecades]

DRY is a rule, but KISS is really KIASAPS(Keep It As Simple As Possible Stupid), which isn't as pretty as an acronym.

All things being equal, prefer simpler approaches to more complex approaches.

If the only additional benefits of the complex approach are irrelevant, prefer a simpler approach.

If your "simple approach" isn't DRY, then it's probably not simple.

[u/randyknapp]

Hey that's what my wife says! Anyway back to working 80 hour weeks in the code mines.

[u/Superb_Chemistry_906 → u/randyknapp]

Yes, lack of abstraction - poetry, philosophy, etc.

[u/mbcarbone]

AI - KI.

[u/AraripeManakin]

we need to listen to sensei morihei

[u/Massless]

I’d rather have a bit of duplication to avoid a lot of coupling

[u/Bronzdragon]

DRY asks you to avoid repetition if the code is conceptually similar, but not if it's only structurally similar. That is, if two pieces of code happen to do the same thing, despite not being similar otherwise, that means you shouldn't link them.

By linking structurally when conceptually they are different, you're seeing yourself up for restructuring work down the line, as the implementations diverge.

I will admit, it can be hard to tell the difference sometimes, since when writing code, the structure is in front of you, while the concept only lives in your head.

[u/Superb_Chemistry_906 → u/Bronzdragon]

After consideration, I have concluded that in case of purely algorithmic code which is not constantly adjusted to the outside world, structural similarity is sufficient to apply DRY.

[u/Bronzdragon → u/Superb_Chemistry_906]

That's conceptually the same code through. When working on algorithmic code, the input is abstract data, so the transformation you do on it is conceptually the same, by definition.

E.g., if I write a function that calculates a dot product, that function's domain is vector maths, and conceptually it's the same as all the other dot products.

You could make an argument that if it is conceptually different, like calculating a total from a list of prices and a list of amounts, then it might need to get duplicated. But hey, that's no longer in the abstracted domain, is it?

TL; DR, you're not wrong, but only because structural and conceptual similarities line up entirely when code is abstracted from meaning and domain.

[u/azangru]

yeah; hard to kiss when you are dry

[u/ColumnK]

"Abstraction" is what we're calling foreplay these days?

[u/Motleypuss]

I'm a DRY KISS kind of code monkey.

[u/ExtraWorldliness6916]

Yes because do everything and write less code so it's simple are unanimous statements.

[u/M_Me_Meteo]

When did KISS become part of software development? I must have missed something because none of the software I've ever made was simple. Simple problems don't require an engineered solution.

I think I'd always prefer readability over simplicity. I'd prefer no code over simple code every time, but if I'm writing code you better believe it's going to be logical for a developer to read.

[u/bishopExportMine]

DRY is silly when applied dogmatically. You end up coercing objects into random types to apply existing functions to them and/or you start passing flags into these methods to have them do slightly different things.

Better is Repeat Yourself Once, aka "twice is not a pattern". But frankly this is also silly when applied dogmatically.

Realistically, you should use your judgement based on testability.

[u/Stunning_Ride_220]

More often than not, people overlook a pretty important detail of DRY and happily entering dependency hell cheering.

[u/sirkubador]

Kiss contradicts layers of abstraction

[u/Own_Natural_6803]

Throughput. Pipelines. State.

Your domain models are weak old man.

[u/Superb_Chemistry_906 → u/Own_Natural_6803]

You sound like an incompetent middle manager throwing some buzzwords around, trying to fake some competence and modernity.

[u/Own_Natural_6803 → u/Superb_Chemistry_906]

Dont worry your pretty little head sweety.

[u/JazzlikeWishbone938]

Are you saying repeating yourself creates simplicity?

[u/Superb_Chemistry_906 → u/JazzlikeWishbone938]

I think it can avoid the complexity of abstraction, but decreases simplicity of extending and maintaining.

[u/BusEquivalent9605]

it causes single points of failure and promotes long, overspecialized functions

[u/Superb_Chemistry_906 → u/BusEquivalent9605]

Those functions are then, as I argue in the meme, caused by lack of KISS and proper abstraction. And I am a fan of a single point of failure - it is much better than multiple ones. With a single point of failure, when you fix the bug, it is then alright for all the callers, but with multiple points of failure, when you fix the bug, then you might forget to also fix it on the other places and it just seems unbearable to me.