You can do both with microservices!
But wait! There's more!
For $19.95, you can replace your single single point of failure with multiple single points of failure!
Prefer duplication over the wrong abstraction (2016)
11–20 of 375 posts
Re: Prefer duplication over the wrong abstraction (2016)
#12You can do both with microservices!
Except 9/10 times microservices end up wildly dependent on each other, yielding a distributed monolith. Better to use service oriented architecture and just ship the monolith, you can test easier and skip the extra layers of serialization / deserialization.
Re: Prefer duplication over the wrong abstraction (2016)
#13I used to struggle with abstractions back in my OOP days but since moving pretty much to a purely functional approach I find that code duplication is rare. Just have a function and call it in two parts. The main abstraction issue is then data structures but with TypeScript interfaces being duck typing essentially I run into few problems there as well.
So code duplication because of abstraction issues is rare. Code duplication because of siloed developers is so much more common.
Re: Prefer duplication over the wrong abstraction (2016)
#14The problem with coming up with a rule that works for everyone is that everyone have a different idea of what makes a good abstraction. Do you want to iterate using for loop or using .iter().step(2).map()? I would rather have consistency than a mixed bag of levels of abstractions.
> Do you want to iterate using for loop or using .iter().step(2).map()?
This isn't really a good example, assuming both can be used to represent the same thing.
The problem with the wrong abstraction is when your abstraction doesn't let you represent something. Then, because of you've already invested so heavily into it, you start contorting the problem to fit your abstraction and it becomes a shit show.
Re: Prefer duplication over the wrong abstraction (2016)
#15i recall very early in my career i did exactly this. i took what worked duplicated it—my reasoning being that it was far safer to reuse what has been battle tested and leave refactoring at a later stage it wasn't received well and senior developer told me that 'good developers know exactly what patterns to use all the time before writing any piece of code and that he will clean up my mess' long story short his refact…
It's definitely an "it depends" thing. It's easy to overabstract. On the other hand, I've also met junior developers who just didn't know how to use function parameters.
Re: Prefer duplication over the wrong abstraction (2016)
#16This is the biggest lesson I got from LMMs. I have a 1 million LOC vibe coded project that I can only imagine would fit in a few hundred thousand lines. But it's still holding up, I expected some kind of development collapse long before this point.
Well sooner or later I would expect a developer who intimately understands their code base to feel compelled to start refactoring and extracting fitting, meaningful well-leveraged abstractions.
Re: Prefer duplication over the wrong abstraction (2016)
#17You can do both with microservices!
Except 9/10 times microservices end up wildly dependent on each other, yielding a distributed monolith. Better to use service oriented architecture and just ship the monolith, you can test easier and skip the extra layers of serialization / deserialization.
I think you missed GP's point
Re: Prefer duplication over the wrong abstraction (2016)
#18No it's not.
Re: Prefer duplication over the wrong abstraction (2016)
#19+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.
Re: Prefer duplication over the wrong abstraction (2016)
#20Depends. If the abstraction is just a level of indirection, then it is usually pretty simple to eliminate - just hit “inline function” in the refactoring tool a few times.
On the other hand it is pretty difficult and error prone to consolidate duplicated code which have drifted apart over time.
If in doubt, chose the approach which is simplest and least risk to revert if you discover in the future you made the wrong choice.
I do agree a bad abstraction can cause huge problems. But it’s usually not the kind of abstractions introduced to eliminate code duplication, but the kind of top-down “architecture astronaut” abstractions, where a model is chosen which does not fit the complexity of the problem.