upvote
> Wouldn't most large codebases with poor abstractions just have engineers engineer around them with their own solutions?

Obviously, yes. But it is my experience that this happens more slowly and that API invocations that break when the abstraction is changed are much easier to identify than broader duplicated patterns of code that span many lines and subtly diverge.

And even then those divergences are better because each wrapper around the abstraction is documenting the problem with it. But the abstraction can generally be replaced by one with the same API surface.

(Even if you take into account the fact that any API behaviour ultimately gets relied upon even if undocumented. Which is true.)

To be fair my experience is that of a freelancer and contractor who arrives trying to fix things that have been through many such hands. And I think if these developers had it drummed into their head that any attempt at abstraction would be better than copy and paste, these situations would be more knowable.

reply
> engineers engineer around them with their own solutions

When that happens there's a major engineering leadership failure currently in progress, even if engineering leadership isn't aware of it.

reply
Yep, this is why I why I find talking about this tiring. No matter what you say, many people are going to keep reading it as "duplication is always better than abstracting."
reply
It's more nuanced than either extreme. But regardless of the root cause, if you have engineers duplicating work left and right something has gone wrong. Their labor is not being used efficiently.

EDIT: LLM or not, this is still true. If you have LLMs pumping out tons of duplicate code you're wasting tokens, and probably more importantly wasting engineer hours reviewing duplicate code.

In some cases it might be a fair trade, in moderation. In general it's certainly wrong.

reply