Nobody wants to listen. Nobody. In 90% of the companies there are some so called senior devs that get ecstatic when they create a new abstraction.

Overengineering, abstractions and premature optimisation are the 3 worst plagues of engineering.

At the same time I’m happy they exist because it means we’ll always have a job.

Cheaper is skipping a step.

Code duplication and 'wrong' abstractions both count themselves amongst the other foibles of programming. But they don't directly produce a cost which can be cheap or expensive.

They produce some other high dimensional intermediate value which can then produce highly variable cost dependent on the domain, goals, and scenario.

As ever, it depends.

The depends is quantifiable, but it doesn't fit in a blog post. Think more along the lines of war and peace.

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.

I once used code duplication to implement a fourth type of dialog that looked somewhat similar to the others, that were sharing a lot of code, because I felt that although it looked much the same as the others, there was some fundamental difference. Took me about a day to implement. When some other engineer saw this, he spend the next three weeks trying to integrate all of them with some shared class. His work was not completely worthless, because he did find some small bug during all his efforts to avoid any possible code duplication. I already had predicted that it would take a lot effort, but I did not object, because I hoped that he would learn something from it and the next time think twice before always trying to avoid code duplication.

The generic repository "pattern" is the prime example of this. There might be CRUD operations shared between repositories, but they should not be that base of every repository. I've seen this so many times, because in the beginning the CRUD stuff is what you code over and over again and then suddenly business logic emerges and everything breaks down, but the repository prevails because sunk cost fallacy ...

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.

> Programmer A sees duplication.

This step should also be parameterized by how many times the duplication has occurred. Refactoring preemptively may lead to poor abstractions, but not refactoring after seeing the exact same thing tens of times would also be weird. See also:

https://wiki.c2.com/?DuplicationRefactoringThreshold

https://wiki.c2.com/?ThreeStrikesAndYouRefactor

I would argue that _premature_ abstraction is worse than _some_ duplication of code.

Also I’ve seen the kind of codebase that seems to be LZW packed due to the sheer desire to DRY everything out. Not pleasant thing, by the time you goto 10 layers deep on some “helper” function you forgot why you in there.

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.

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.