Is "opinion-driven design" an attempt to reinvent YAGNI and to try to pass it off the concept as a brand new discovery?
People are very good at handling rules with one exception. All mammals are live birth except platypuses. All accounts have foo unless you live in California. Et cetera. Two implementations of a bit of logic is just a case of this.
When you get to three cases, you’ve lost the plot. You have to reformulate the question to restore the two-ness of the system (even if that’s splitting it into two twos), otherwise it doesn’t scale conceptually.
YAGNI isn’t a rule, it’s a dismissal. A dodge. A cop-out. As such, it gets misused, all the time. Anyone who wants to sound smart and be lazy will just say YAGNI, and it takes a lot of experience with a person to know whether they’re just lazy or lazy like a fox.
The Rule of Three is concrete. It contains a contract/escape hatch which prevents inaction from becoming unbounded.
And when properly employed, is extremely effective.
The trick is to know when the A stands for "ain't", and when the A stands for "are".
Only when the abstractions proposed actually have a pragmatic use. As developers, for a lot of us, the immediate instinctual reaction is "add another layer of indirection". Each of these makes the software more complex, adds cognitive load and increases tech debt, making it a risky proposal.
Those risks are often glossed over for purely philosophical benefits and - for lack of a better term - personal taste. Maybe you don't actually need factories, strategy patterns or even DI just because the Gang of Four book mentions it. Maybe worry about problems when they occur, not because the might occur.
YAGNI is just a concrete implementation of KISS. I prefer the approach it proposes: question everything, say yes only when it makes sense. That is what YAGNI symbolises and reduces use cases, scope, feature creep and abstraction creep. For most companies, code isn't what's sold and merely enables (parts of) the business. What matters is whether it's fit for purpose, not whether it smells nice.
No, not really. YAGNI is about making it clear that you do not need to waste time putting together abstractions that aren't required to implement anything, and are nothing more than nice-to-haves that increase complexity but buy you nothing.
At best, YAGNI is a tradeoffs between the risk of piling up tech debt (and typically a very low risk) and improving the maintainability of your code base (because you avoid piling up cruft that you do not need).
That's not how it gets used most of the time now. It is rare that I hear someone use it the way it was meant to be used.
That's what YAGNI still is and always was. It never changed. At all.
Another thing that never changed are those who criticize YAGNI because they feel the abstraction they wish to add is somehow a must when it really isn't.
Is there any difference at all?
They're complementary though.
I mean, let's be honest here: "you ain't gonna need it". That's what YAGNI stands for, and represents. That's what you say to anyone who claims "but it would be far more flexible if...". It's YAGNI, no matter how much makeup you want to slap onto it.