YAGNI as a development concept is a very powerful idea. The idea of making a decision at the last responsible moment saves money, effort, rework, and will often save sanity. The idea is very simple and bascially revolves around removing speculation. When we constantly think in terms of YAGNI, we are often mitigating one of the largest risks to software projects.
In my experience, extensibility is usually the largest risks to a software project because it often results in the largest degree of over-engineering. This usually isn't a popular idea, but I think it's true. There are times when it's warranted and valuable, but the problem is that we tend to always think that it's valuable. We always say things like: "what if", "someday", "it's possible that", "I can imagine a scenario", and so on. These are usually things that should be considered, but not always things that should be developed. In theory, we need to pose these questions to our stakeholders and our stakeholders should be making these decisions (not the development team).
The problem with the theory (allowing the business team to make the decisions) is that they are often caught up in the same vicious cycle of over-engineering our specifications. When I'm handed a large requirements specification document, I know that 25% of it is outdated, 40% of it will never be implemented, and that the real value likely comes from 20% of the requirements. The state of the specification is a result of over-engineering by the stakeholders (and it compounds the issue of over-engineering by the development team).
I don't have a silver bullet to fix the issue, but I believe that we can at least identify the problem and get in the correct mindset of fixing the problem by thinking about how to eliminate waste. Simply considering known value vs. speculative value can go a long way. We should always be thinking about doing less. Less is a powerful idea because of the compounding growth of each additional thing that we choose to do. For every "I can imagine" scenario, we have business costs, development costs, testing costs, and maintenance costs. We also have other costs that we usually don't think about including opportunity costs.
To push the idea further, we should consider the idea of "less" across the spectrum of our activities. One big opportunity comes with documentation. I think that The Elements of Style should be required reading for everyone that contributes to documentation on a project. Our documentation should be concise and avoid all the additional "fluff" that makes up the majority of the large documents that I see on typical projects. Documents should be focused to the point that every word in the document has meaning just as every requirement should be valuable and every bit of software should be testable.
Unfortunately, the idea of more is the norm. The positive side is that we are the problem and we can all take steps to eliminate waste in our day-to-day activities. If we don't do anything else, we should at least consider how the idea of "less" can apply to our projects and our organizations. It's not an overnight change, but it is a valuable exercise in thinking about what really matters.
