Prefer duplication over the wrong abstraction (2016)

cryo32

You can do both with microservices!

antonymoose

Twice a coincidence, thrice a pattern.

anon-3988

The problem with coming up with a rule that works for everyone is that everyone have a different idea of what makes a good abstraction. Do you want to iterate using for loop or using .iter().step(2).map()? I would rather have consistency than a mixed bag of levels of abstractions.

christophilus

Yes. I’m dealing with a graphql, urql, Next, Prisma stack at the moment. Something that would be a handful of lines of code in a different stack ends up being hundreds in this one. The Node ecosystem is full of wrong abstractions.

KHRZ

This is the biggest lesson I got from LMMs. I have a 1 million LOC vibe coded project that I can only imagine would fit in a few hundred thousand lines. But it's still holding up, I expected some kind of development collapse long before this point.

platz

2016 (up to 2018 or so) may have been the peak of such varied activity in the developer ecosystem, including articles like this, whether it was discussion, ideation, OSS variety, language development. There has been growth since but it's been concentrated into fewer channels and somewhat industrialized.

agentifysh

i recall very early in my career i did exactly this. i took what worked duplicated it—my reasoning being that it was far safer to reuse what has been battle tested and leave refactoring at a later stage it wasn't received well and senior developer told me that 'good developers know exactly what patterns to use all the time before writing any piece of code and that he will clean up my mess' long story short his refactoring caused what was otherwise a stable system into a complete mess and it reminded me of Nassim Taleb's book

bhouston

I used to struggle with abstractions back in my OOP days but since moving pretty much to a purely functional approach I find that code duplication is rare. Just have a function and call it in two parts. The main abstraction issue is then data structures but with TypeScript interfaces being duck typing essentially I run into few problems there as well. So code duplication because of abstraction issues is rare. Code duplication because of siloed developers is so much more common.

atmanactive

No it's not.

znkr

+1 The worst code I had to maintain was code that tried to follow DRY (without the trying to understand what the original intention of that principle was). The only way out of that mess was widespread code duplication.

bazoom42

Depends. If the abstraction is just a level of indirection, then it is usually pretty simple to eliminate - just hit “inline function” in the refactoring tool a few times. On the other hand it is pretty difficult and error prone to consolidate duplicated code which have drifted apart over time. If in doubt, chose the approach which is simplest and least risk to revert if you discover in the future you made the wrong choice. I do agree a bad abstraction can cause huge problems. But it’s usually not the kind of abstractions introduced to eliminate code duplication, but the kind of top-down “architecture astronaut” abstractions, where a model is chosen which does not fit the complexity of the problem.

strongpigeon

Echoing the article, anyone who has experienced both will agree: it’s far easier to work with an under engineered code base than an over engineered one.

jstimpfle

Code duplication is the wrong abstraction too -- unless it's not really code duplication but code that only happens to be similar for some really "unstable" reason.

dofm

No it's not. This has always been a needlessly iconoclastic rather than sensible suggestion. At the very least it is not once you're working at the wrong kind of scale. Once you have an awkward number of customers (more than five and less than a hundred), maintaining duplicated code that should have been abstracted and modularised will only seem cheap if you don't mind that you burn through even junior employees at a pace. And in the LLM era the wrong kind of scale appears in different ways; code generated and duplicated without proper abstraction and then maintained by an LLM that cannot be trusted to do the same modification each time it encounters a pattern or to have enough of an overview to slowly rescue duplicated code through good abstractions. I would go as far as to say that any abstraction you can maintain (that is in active maintenance, I mean) is better than code duplication once you are past a de minimis threshold.

bob1029

If you work backward from the schema these sorts of things tend to evaporate before they can become a problem. Some of the biggest rabbit holes come from naming conventions not aligning across the business and technology silos. If everyone agrees that Customer has exactly 34 attributes, then it is possible to move to the next step of sharing libraries of types across the team. Getting your POCOs/DTOs 1:1 across the board is when the duplication really starts to melt away.

sebastianconcpt

Oh the self-contradiction here... Generalizing this in the abstract is a wrong abstraction.

northisup

Duplication is fine, triplication and above is the issue.

williadc

The "99 Bottles of OOP" book mentioned at the bottom was an excellent introduction to refactoring. I highly recommend it if you struggle with finding the right data models for the problems you work on.

jbvlkt

It depends if duplication is accidental or real. I.e. if two taxes are using the same formula, it is accidental. If you use the same physic formula on multipla places, it is real duplication.

originalcopy

While I see the point, I think I more often encounter the opposite. Duplication, but not exactly duplication. Then the "sunk cost fallacy" is not an issue but there is huge maintenance cost and no-one feels like refactoring it. I'd rather refactor bad abstraction than 10x duplication.