Comment by joshstrange
4 months ago
The amount of premature optimizations and premature abstractions I’ve seen (and stopped when possible) is staggering. Some people just really want to show how “clever” they are solving a problem that no one asked them to solve and wasn’t even an issue. Often it’s “solved” in a way that cannot be added to or modified without bringing the whole house of cards down (aka, requiring a rewrite).
I can handle premature optimization better than premature abstraction. The second is more insidious IMHO. I’m not throwing too many stones here because I did this too when I was a junior dev but the desire to try and abstract everything, make everything “reusable” kills me. 99.99999% of the time the developer (myself included) will guess /wrong/ on what future development will need.
They will make it take 2s to add a new column (just look at that beautiful abstraction!) but if you ask them to add another row then it’s a multi-day process to do because their little abstraction didn’t account for that.
I think we as developers think we can predict the future way better than we can which is why I try very hard to copy and paste code /first/ and then only once I’ve done that 3-4 times do I even consider an abstraction.
Most abstractions I’ve seen end up as what I’ve taken to calling “hourglass abstractions” (maybe there’s a real name for this I don’t know it). An hourglass abstraction is where you try to abstract some common piece of code, but your use cases are so different that the abstraction becomes a jumbled mess of if/else or switch/case statements to handle all the different cases. Just because 2 code blocks “rhyme” doesn’t mean you should abstract them.
The 2 ends of the hourglass represent your inputs/outputs and they all squeeze down to go though the center of the hourglass (your abstraction). Abstractions should look like funnels, not hourglasses.
No comments yet
Contribute on Hacker News ↗