One way I like to think about is that often abstraction is an automation for a task that doesn't need automating.

You hardly ever change the thing and if you do, changing it in two or three places 'manually' is really not a big deal.

Now changing something fairly often, that affects logic in 50+ places? Then it makes sense to automate with an abstraction so it all flows through the same lines of code.

I know I've personally spent way more time over the years debugging bad abstractions than changing things in a few places.

Related. Others?

The Wrong Abstraction (2016) - https://news.ycombinator.com/item?id=35927149 - May 2023 (69 comments)

The Wrong Abstraction (2016) - https://news.ycombinator.com/item?id=27095503 - May 2021 (17 comments)

The Wrong Abstraction (2016) - https://news.ycombinator.com/item?id=23739596 - July 2020 (240 comments)

The Wrong Abstraction (2016) - https://news.ycombinator.com/item?id=17578714 - July 2018 (207 comments)

Prefer duplication over the wrong abstraction - https://news.ycombinator.com/item?id=12061453 - July 2016 (96 comments)

The Wrong Abstraction - https://news.ycombinator.com/item?id=11032296 - Feb 2016 (119 comments)

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.

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.

You dont know immediately if something that superficially seems the same actually is.

Copy and paste once is fine, twice, not so much.

Often I've seen two totally different things exist in one bit of code, no overlap!

Premature generification is bad, and leads the developer to believe that two things are the same, making it harder to see they are not.

Also, can make it much harder to see that a different abstraction would give a cleaner outcome....

The bad thing with abstractions is when you start it too early in your code base for things. It's also a bad thing when you start it too late, although not as bad. If you start it way, way, way too late it's very, very, very bad.

Of course, the worst abstractions are the ones you don't need at all.

I always try to design in a way, that using abstractions/shared logic is optional.

I've worked in too many projects, where every new feature needs to be built on top of existing abstractions, that often lead to severe restrictions if something slightly different is required. I always try to create reusable units/components, that can either be used as intended or replaced by something that behaves slightly different if needed.

Components are not necessarily frontend components, this extends also to backend logic.

The disadvantages of duplication are greatly reduced in the world of AI. From my experience it can easily detect the duplicates and refactor code safely. On the other hand, code without abstractions is easier to read and easier for AI.

With AI, we really need to rethink the clean code principles.

One thing I don't see talked about often is the fact that not all duplication is equal. Duplicated html/xml/markup does not equal template-based boiler plate, which does not equal almost everything else. I'm far more forgiving of duplicate html/markup because that code is so cheap.

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.