Prefer duplication over the wrong abstraction (2016) • Hacker News Board

Re: Prefer duplication over the wrong abstraction (2016)

#141

Post by dofm » Sun, Jun 21, 2026, 6:16 PM UTC

Thaxll wrote: post #111

dofm wrote: post #25

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…

So you centralize 3 liners?

I said "beyond a de minimis threshold".

But in one of the scenarios I mention earlier, I earned a chunk of money once fixing an issue that emerged in a subcontractor's four or five line duplication that had ended up rippled through a long-lived codebase. A ground truth (MySQL version) changed, and the pattern broke everywhere, including places where it had evolved.

So I tend towards thinking, yes, any three-line pattern that is likely to appear everywhere should, perhaps, be centralised.

It's certainly worthy of serious consideration. Usually pretty easy to maintain the surface of such an abstraction.

Re: Prefer duplication over the wrong abstraction (2016)

#142

Post by grayclhn » Sun, Jun 21, 2026, 6:19 PM UTC

dofm wrote: post #63

coldtea wrote: post #47

Earlier quoted context omitted.

Hardly iconoclastic, it's a very sensible suggestion. It would be iconoclastic if the common sense basic approach would be to start with abstraction. It's not, the common sense default is to write possibly duplicate behavior until you actually discover several cases to abstract away, until you bevalop a sensible idea of which functionality unites them and which doesn't carry over all of them. > Once you have an awkwa…

> Maintaining the wrong abstraction, or, god help, abstractions, would be even worse. Hard disagree. When you've had to chase through a change in untold and actually unknown numbers of duplications of code in different permutations and fix them because they are all on fire simultaneously, you'd disagree too. A bad abstraction would at least have had one fire in one place.

IME a bad abstraction results in the same thing, just with a lot of wasted effort coming up with the abstraction first, and a lot more resistance to fixing it because people are too emotionally invested. I’d rather have something clearly chosen for expedience and that no one likes.

Re: Prefer duplication over the wrong abstraction (2016)

#143

Post by coldtea » Sun, Jun 21, 2026, 6:21 PM UTC

dofm wrote: post #126

coldtea wrote: post #110

Earlier quoted context omitted.

> A bad abstraction would at least have had one fire in one place. On the contrary: that's precisely what a bad abstraction would not offer. Instead it would spread its assumptions to different parts of the system, as every caller, sub-service, etc. would have to change shape to fit in that abstraction's box, however unnatural it is (and we know it would be unnatural, because we already said it's a bad abstraction).…

> instead it would spread its assumptions to different parts of the system, But so does duplication, in practice, and it diverges more as it does.

Duplication is just code doing the same thing in several places, and as such it's much easier to make DRY (and much easier after you have N copies to see what should be shared and what should not), compared to re-architecting the whole system to remove a bad abstraction.

Re: Prefer duplication over the wrong abstraction (2016)

#144

Post by coldtea » Sun, Jun 21, 2026, 6:24 PM UTC

marcosdumay wrote: post #130

bluefirebrand wrote: post #54

Earlier quoted context omitted.

Yeah, "Write Everything Twice" is a pretty common and sensible direction for any codebase

It's sensible if you have strict control of your duplications. You do have strict control of what is duplicated and where, right? Write everything twice quickly becomes write everything 4 times once a new change appears, just as quickly as it becomes write everything 8 times, and so on. I'm afraid there's no sensible soundbite developers can follow blindly.

>Write everything twice quickly becomes write everything 4 times once a new change appears, just as quickly as it becomes write everything 8 times, and so on.

That's a good problem to have. Getting to 4 or 8 or 12, and then pruning it to 1 or maybe 2 or 3 clearly different cases, is better than shoehorning multiple cases into the wrong abstraction, having everything that speaks with them coupled to that and dancing around their assumptions, and then having to untangle that.

Duplicated code is by definition LESS coupled.

Re: Prefer duplication over the wrong abstraction (2016)

#145

Post by zephen » Sun, Jun 21, 2026, 6:24 PM UTC

loevborg wrote: post #17

DJBunnies wrote: post #12

Earlier quoted context omitted.

Except 9/10 times microservices end up wildly dependent on each other, yielding a distributed monolith. Better to use service oriented architecture and just ship the monolith, you can test easier and skip the extra layers of serialization / deserialization.

I think you missed GP's point

Poe's Law FTW!

Re: Prefer duplication over the wrong abstraction (2016)

#146

Post by pfannl » Sun, Jun 21, 2026, 6:24 PM UTC

coldtea wrote: post #47

dofm wrote: post #25

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…

Hardly iconoclastic, it's a very sensible suggestion. It would be iconoclastic if the common sense basic approach would be to start with abstraction. It's not, the common sense default is to write possibly duplicate behavior until you actually discover several cases to abstract away, until you bevalop a sensible idea of which functionality unites them and which doesn't carry over all of them. > Once you have an awkwa…

The real rule is probably: duplicate until the abstraction stops looking like a horoscope.

Re: Prefer duplication over the wrong abstraction (2016)

#147

Post by nullbio » Sun, Jun 21, 2026, 6:24 PM UTC

Code duplication is terrible in the age of LLMs, unless you want to maximize on drift.

Re: Prefer duplication over the wrong abstraction (2016)

#148

Post by blauditore » Sun, Jun 21, 2026, 6:24 PM UTC

stymaar wrote: post #114

fny wrote: post #35

Earlier quoted context omitted.

Code duplication is cheaper than the wrong abstraction. If you have a good abstraction, you should run with it. If you haven't figured out a good abstraction at 5-100 customers, God help you.

> Code duplication is cheaper than the wrong abstraction This is tautological though, it's like saying “starving is much better than eating the wrong food” (for instance: eating quick lime). Of course you'll always find a way to do things wrong in a way that is costlier than not doing anything.

Sure, but obviously that sentence implies that wrong abstractions are fairly common.

Re: Prefer duplication over the wrong abstraction (2016)

#149

Post by ubertaco » Sun, Jun 21, 2026, 6:26 PM UTC

dofm wrote: post #25

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…

I'd recommend clicking through the headline to watch the talk. Metz talks a lot about types of similarity: similarity by coincidence vs similarity due to an actual semantic or functional equivalence.

Code that is coincidentally similar very often diverges in either the short or long term, and DRYing it up aggressively tends to result in functions that have many boolean parameters that each trigger disjoint sets of behavior - which is a bit of a nightmare to maintain due to the high cognitive overhead of remembering how all the interleaved-but-actually-unrelated behaviors should work.

This outcome is low-cohesion code.

It's a useful concept to be aware of - worth clicking through to the actual content of the talk rather than just the headline.

Re: Prefer duplication over the wrong abstraction (2016)

#150

Post by swader999 » Sun, Jun 21, 2026, 6:27 PM UTC

dofm wrote: post #63

coldtea wrote: post #47

Earlier quoted context omitted.

Hardly iconoclastic, it's a very sensible suggestion. It would be iconoclastic if the common sense basic approach would be to start with abstraction. It's not, the common sense default is to write possibly duplicate behavior until you actually discover several cases to abstract away, until you bevalop a sensible idea of which functionality unites them and which doesn't carry over all of them. > Once you have an awkwa…

> Maintaining the wrong abstraction, or, god help, abstractions, would be even worse. Hard disagree. When you've had to chase through a change in untold and actually unknown numbers of duplications of code in different permutations and fix them because they are all on fire simultaneously, you'd disagree too. A bad abstraction would at least have had one fire in one place.

The article isn't saying don't dry, it's saying don't force dry. Very big difference and you get ideal maintainability when you ease off a bit but still use it.