YAGNI is my favorite principle when I build and implement any system.
YAGNI is an abbreviation of You Aren’t Going to Need It, and it is all about avoiding over-engineering and sticking to the current requirements.
Given that requirements change often, due to changes in prioritization or user adoption, spending time doing things that will never be used is a complete waste of time and effort. YAGNI safeguards us against this uncertainty enabling us to iterate rapidly.
One example of this is the creation of abstract classes and interfaces for every single damn thing. You chose to abstract out the DB layer on day one because just in case you might change your database in the future is the epitome of wasting engineering bandwidth.
Such abstractions add additional code to read and understand, which adds to the cognitive load to make further changes, especially during the early days when you should be prioritizing execution over extensibility.
I am not saying not to add interfaces or abstract classes. Small efficiency habits that are not time-consuming and do not make the implementation “highly complex” are okay to implement. So, before you implement just ask yourself, is this something we should be doing right now?
ps: I have taken low-level abstractions as an example, the argument holds when you unnecessarily create microservices or go for the most “scalable” database on day zero.
ps: admissions open for sys design feb cohort - arpitbhayani.me/course