Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "premature abstraction"
-
To be honest with you, I’ve never had a bad experience with PHP.
Yes, it’s “dirty” compared to something like Haskell, but it’s not a bad thing. Dirty things usually bring simplicity and allow implementing the intended case super quickly, at the cost of breaking apart at scale. There are no bad tools, there are wrong tools for the job.
Premature optimization is the root of all evil. The more I launch new projects for me/other companies, the more I come to the realization that the vast majority of the projects out there will never see scale. They will be proven non-viable/impractical and deemed obsolete way before they outgrow the $20 VPS they were hosted on.
Sometimes (all the time, really) launching quickly like there is no tomorrow is the most viable business strategy. If (yes, “if”, not “when”) your project outgrows PHP and gets to the point when PHPs abstraction model is the bottleneck, you’ll have the money to rewrite the project in any language out there, trust me.
As someone said on biking subreddit to a person that asked how to buy the newest super-aero helmet, “if the aerodynamics of the old helmet is what holds you back, someone will be sending you the new one for free”.6 -
Sometimes people want to be too smart. If you want to consume a handful different restful API, it might make sense to abstract away some common functionality in your client implementation — yet to assume they follow the same convention in how their URI is built is borderline insane.
All I wanted to do was to change one API to a newer version, and now the implementation breaks for at least two other because it was done in an Abstract class and now I have to untangle that mess.
In some cases code duplication wouldn't be that bad. Even if an otherwise unrelated API seemingly share the same contract, still assume it has its own contract. You never know how those API evolve and I proclaim they will evolve towards breaking your assumptions.1 -
I go to add a method call in a business logic class that's used exclusively in a particular service, and get blocked in the PR by some other guy-
Other Guy: refactor this into the shared framework referenced by all our microservices
Me: it is only and would only be used in this service
OG: what about the other business logic class in this service?
Me: it's not used there, and if it does end up used there then we can refactor it into a class that they both reference then
OG: I need to know when the abstraction of this function will be done. is it going to be delivered next sprint?
Me: YAGNI - better to avoid doing extra work when we don't know if we'll even need it
OG: tbh you can still abstract it with some generics and lambda magic, but im not gonna enforce that
Me: premature abstraction is the root of all evil (tongueout)
OG: not really, its the root of not having a million miles of tech debt in 2 years
I just can't win for losing with the anti-YAGNI yogi.1