I don’t buy “duplication is cheaper than the wrong abstraction” (2021)
This is a very amateurish take
The author very clearly (at least at the time of writing this) has not dealt with complex code bases.<p>&gt; If I were to see a confusing piece of code littered with conditional logic, I wouldn’t see it and think “oh, there’s an incorrect abstraction”, I would just think, “oh, there’s a piece of crappy code”. It’s neither an abstraction nor wrong, it’s just bad code.<p>This is the primary issue.  The author does not recognize that poor abstractions can involve more than just a lot of conditional logic.  That sometimes, that conditional logic bubbles in places where secondary to where the bad abstraction was made.<p>A simple (real) example of this.  One seen code where &quot;get, these two objects share a field, let&#x27;s pull out a base object and have them both inherit from it, after all, duplication is bad!&quot;.  Then later on &quot;hey, here&#x27;s two other objects with the same field, but they don&#x27;t have that old base objects field, duplication is bad, so let&#x27;s make a third base class&quot;<p>This sort of thinking resulted in a really gnarly object graph.  But further, down stream code had to do type checks and casting to compensate for this bad abstraction.<p>All because the original dev didn&#x27;t want to duplicate a field on two otherwise unrelated objects.<p>And worse, you the dev that works on this code years later are left with the option &quot;keep it as is, of rewrite and touch 100s of files potentially breaking large amounts of code).&quot;<p>Oh, not too mention the unit tests that accompanied such code, ironically, filled to the brim with duplication around this hierarchy making minor charges massive.<p>On smaller less complex code bases you rarely see this comedy&#x2F;tragedy play out.