> YAGNI isn’t a rule, it’s a dismissal. A dodge. A cop-out. Only when the abstractions proposed actually have a pragmatic use. As developers, for a lot of us,

> YAGNI isn’t a rule, it’s a dismissal. A dodge. A cop-out. 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.