[deleted]
Prefer duplication over the wrong abstraction (2016)
201–210 of 375 posts
Re: Prefer duplication over the wrong abstraction (2016)
#202I believe that "single source of truth" is a principle that should always be followed. If there's duplicated code where it'd be a bug if they diverge, then you should refactor. It creates a long-distance coupling in your code that may be invisible to future developers until a bug emerges. But with that in mind, I mostly agree with the article: if it's not a violation of "single source of truth", then abstractions are…
Of course, in theory this is true. In practice people tend to avoid ANY duplication no matter what. Especially junior developers, as if duplication would be the root of all evil.
This is something I've seen repeated time and time again as a criticism of (misused) abstraction and DRY, yet I've never seen ONCE -- and this is not hyperbole, I mean it literally -- a junior making an abstraction with any thought to reuse, generalizing anything, or caring about not repeating code. Most juniors I've worked with are content to just churn new code without paying attention to the codebase at all. This all before the AI deluge, mind you.
Very similar with patterns. I've often read people protesting that juniors overuse design patterns, yet I've seldom seen a junior (mis)use anything more complex than a singleton, and when they use any pattern, it's usually forced upon them by an opinionated Java framework.
Re: Prefer duplication over the wrong abstraction (2016)
#203I always felt like I abstract and modularize things way less eagerly than other programmers. Was pleasantly surprised to find that LLMs do it mostly my way by default, then again they're also bad at abstracting when it's actually needed.
Re: Prefer duplication over the wrong abstraction (2016)
#204Earlier quoted context omitted.
You mean you don’t have 300 versions of your badly developed rapidly evolving platform services rotting away underneath the bit you didn’t duplicate?
I don't. Other teams - maybe they do, maybe they don't. Who cares, not me. I have responsibility for services of my team, I think we are doing a good job. Being selfish is the core principle of microservice architecture.
Until half your company gets laid off and you have to adopt other people’s shit.
Re: Prefer duplication over the wrong abstraction (2016)
#205One 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.
Re: Prefer duplication over the wrong abstraction (2016)
#206I think what this advice is really getting to, is that you should prefer everything generally build-time/hardcoded/static rather than runtime/dynamic. Wrote about this in 2013 (calling it a CMS trap[1], back then seemed pertinent).
Re: Prefer duplication over the wrong abstraction (2016)
#207I always felt like I abstract and modularize things way less eagerly than other programmers. Was pleasantly surprised to find that LLMs do it mostly my way by default, then again they're also bad at abstracting when it's actually needed.
I think LLMs are trained to not refactor. I think it’s either that you would need to do something in training to make them want to do it and the labs don’t do that, or that the labs correctly guess that it would be very annoying for LLMs to go and refactor your existing code as they go. This creates bad effects (eg crazy hacks to avoid refactoring and, much worse, not refactoring the code they only just wrote as required) but I think the alternative would be worse – it’s not something you always want to read and the refactoring is often done incorrectly, restructuring the code to the best shape for the current task rather than something that balances many different needs.
Re: Prefer duplication over the wrong abstraction (2016)
#208+1 The worst code I had to maintain was code that tried to follow DRY (without the trying to understand what the original intention of that principle was). The only way out of that mess was widespread code duplication.
Yep. Keyword "tried," as in they did it for a while then hit a point where it's impossible to faithfully follow the abstractions because they're wrong.
Re: Prefer duplication over the wrong abstraction (2016)
#209This is like saying "A slow leak is cheaper than a burst pipe" Yes, okay. But with both you will have a bad time cleaning up. There is a third option: good abstractions. I did see this pattern described in the blog in practice a lot (and fell victim to it myself) and I think that in general this comes down to inexperienced programmers. Object oriented programming makes it worse. Teaching these programmers that they s…
The saying is you build better abstractions if you don't build them too early.
Re: Prefer duplication over the wrong abstraction (2016)
#210Earlier quoted context omitted.
> 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.
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."
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.