| ▲ | davidee 2 hours ago | ||||||||||||||||
Good faith question: would it? Wouldn't most large codebases with poor abstractions just have engineers engineer around them with their own solutions? In a large enough codebase you'd have both the bad abstractions and all the not-quite-duplicate implementations ignoring the bad abstraction? I'm using bad here loosely, it could be buggy, incorrect, incomplete, insufficient and more; while being owned by someone or some team that's a challenge to work with for various reasons (overloaded, under-resourced, overbearing, etc., etc.). | |||||||||||||||||
| ▲ | dofm 2 hours ago | parent | next [-] | ||||||||||||||||
> 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. | |||||||||||||||||
| ▲ | jcgrillo 2 hours ago | parent | prev [-] | ||||||||||||||||
> 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. | |||||||||||||||||
| |||||||||||||||||