I've taken some courses and read about the purposes of YAGNI. But, this principle as a whole has never sat well with me. It introduces a logical paradox.
As a hypothetical, you're designing a framework that you intend to scale forward. YAGNI (and possibly TDD) would encourage you to focus on the now. Make it work for your foreseeable hardware. After all, the requirements for the future are fuzzy and, well, in the future.
But, that inherently limits your framework's viability. And in this hypothetical, you have the foresight to know what the future will hold. It may be worth your time to do some prototyping and working ahead, knowing that it could very well help you down the road. After all, the very essence of a framework is to facilitate some functionality across environments-- so how can you be designing a framework and adhere strictly to YAGNI principles?
I'm not sure if I'm asking for a concrete on "how to use YAGNI"-- I get that it may be more philosophical than that. I might just be asking more seasoned developers in industry where the line is between YAGNI, the antithetical principles, and best practice. Is YAGNI enforced? Is it even regarded? Or is it just something our schools teach us because it's in our books?
Thanks.
YAGNI is an important principle in the real-world development and maintenance of large applications, for a number of reasons. Here are the most compelling:
TECHNICAL COMPLEXITY When working on an industrial-sized codebase, seasoned developers learn considerable reluctance to accept technical complexity into their system. You should not start paying the implicit overhead of extra technical complexity before you need it.
REQUIREMENTS CHURN You may think you have a clear idea of the future requirements of your system, but you may very well be wrong. Statistics suggest that 35% of all features described by Product Owners as a 'must have' for a project are never implemented. Trying to anticipate future requirements and do some of the technical work new leads to wasted effort.
QA FEEDBACK LOOP Any time you do any development on a non-trivial technical system, there will be bugs. This is inescapable. Finding out about a bug on the day of creation vs one year later makes a difference in development cost by a factor of 100 according to some studies. Typing code that cannot be caused to execute through interaction with the UI now 'in case we need it later' is a sign of an inexperienced developer.
In summary, the best code sticks to the YAGNI principle basically all the time, and the best agile teams aim for this. You may think you are making your code easier to work with, more flexible etc. if you show foresight, but this is almost never the case. Code is at its easiest to work with when it is simple, so keep it that way.