Comment by joshstrange

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.