Under-applying YAGNI Results in Terrible Codebases and Not Taking Good Advantage of OOP

It's amazing how few devs understand the YAGNI Software Engineering principle (Ya Ain't Gonna Need It!). This is as true in the Ruby community as it is in other Software Engineering communities. Devs either over-engineer everything with very complicated "Services" or under-engineer everything by using a Functional Programming language or style of development, resulting in a very terrible expensive-and-difficult-to-maintain codebase. Very few Software Engineers are adept at applying YAGNI, understand how to balance division of responsibilities between objects in Object Oriented Programming, and understand that every approach in Software Engineering is valid depending on the problem at hand.

Writing everything in a single script is sometimes good enough. Otherwise, dividing the script into a few Models might be the next good enough approach. If the Models grow too large, then perhaps extracting a Service or few is the next good enough approach, but that doesn't mean devs should be applying that approach everywhere all the time. That's where most devs fail as they try to generalize whatever approach they think is "best" everywhere all the time, and end up resulting in a terrible codebase to work with.

Balance between different approaches is key and being comfortable with imperfection is perhaps the most underrated skill in Software Engineering as it is the skill that ensures properly applying the YAGNI principle whenever needed. Under-applying YAGNI results in terrible codebases and not taking good advantage of OOP when helpful.

One of the most common anti-patterns caused by lack of application of YAGNI is a developer complaining about different parts of a technology and throwing the baby with the bathwater by never using a technology again because it did not solve everything all the time. 

Usually, when I hear a Software Engineer talk with such generalizations, I recognize right away I am talking to an amateur not a real expert in Software Engineering. Software Engineering amateurs usually are always bouncing from one approach to another while seeking the golden hammer that would solve all their problems all the time. One day that is GraphQL, the next day, it is Server Side Rendering, and after that, perhaps Rust, and on and on and on. They never learn to write good code with any approach because they are always seeking a silver bullet while complaining about different parts of a technology because of expecting them to solve everything all the time. 

Like, they might complain about Rails for being "too simplistic with its MVC pattern". So, then they jump on Elixir or Rust and expect it to solve all the problems of the world by throwing the Rails baby with the bathwater. Hello!!! You were never supposed to only apply MVC in Rails, yet just use it as a starting point while augmenting it with proper Object Oriented Design, including application of Design Patterns and Domain Driven Design! 

Those same devs end up eventually ditching Elixir or Rust, and then jumping on the next hype bandwagon, like Next.js or Clojure, etc... Every codebase they build ends up being a complete piece of unmaintainable garbage, and they use that as an excuse to jump unto the next piece of hype. 

Beware of such devs as all they do is scam customers with the illusion of skill while they lack the true deep Software Engineering skills of applying YAGNI and knowing how to use the right tool for the job.