I do. I have seen ton of time wasted due to the wrong abstraction. Through it's a question about how much and what you duplicate. Which means I somewhat part

I do. I have seen ton of time wasted due to the wrong abstraction. Through it's a question about how much and what you duplicate. Which means I somewhat partially agree with the articles which is more well nounced then the title implies. One of the most common case of bad de-duplication is doing so with code which happens to be mostly same but there is nothing on a business logic pov which makes it the same. Or code which differs mainly in points which the language used needs a lot of complexity to abstract over. In my experience having a more power full type system, like in Scala, Haskell or Rust one one side has the benefit of making the refactoring much less bug prone, but also are easier to go into the "abstraction introduces too much complexity" territory. In the end using a type system _appropriately_ is a skill. One some which some technical very skilled people are missing. Through what I also realized is that with strict type system a "top down abstractions" using e.g. custom traits/interfaces/abstract classes tend to be much more likely to cause issues compared to composite bottom up abstractions using closures to fill in the missing part. Sadly this kind of abstraction while simple in the simple case are also prone to need some limited degree of higher kindred typing in the less simple case. This is putting limits on how much you can practically apply them in many languages (or it accidental becoming to complex due to missing intuitive notation for the limited higher kindred type parts needed). Through the most important thing for many projects is to make the code easy to change. And with this I mean changing the source code, not having complicated abstractions allowing you to use the same source code in many different ways even through you only do use it in one way at any point in time.