YAGNI is a very interesting paradigm for most of us that were formerly taught to pride ourselves on “thinking outside of the box” and think “beyond the horizon” when coding.  In the years past, we have typically been given a set of requirements laid out in very vague terms and then given the liberty to make our own decisions and let the technology “limit” the functionality of those requirements.  This model supports the idea of a “Developer as  Executive”.  As David explains in this blog entry, Peter Drucker wrote about this idea in 1966, yet is news to many of us, certainly me.  It does make sense when doing true life-cycle development and implementation, that a “beyond the horizon” event should never be coded for, as you have no use case for it, which means you have no functional requirement, which then ultimately means there is no business driver for the event.  Obviously, if there were any of the 3, it would certainly not be a suprise.  As David mentions, the only time this would qualify is if there is a cost/time savings by doing it now - in which case, I would argue that the scope be re-evaluated to include this requirement as part of the formal process and not merely be an afterthought which can slip through the various phases that the entire project should be subject to.

YAGNI seems almost alien, and you have to tell yourself that you aren't putting out an incomplete product just because you know of something that may happen - until it does, the product *isn't* incomplete.. it performs exactly (or close to) how it should.  Just another example of how turning what we are sometimes taught on its head and going about a project from the top-down, instead of the typical programming mindset of bottom-up makes for more consise code - which ultimately means the project has fewer bugs (as there are fewer scenarios in which the code must behave differently) and comes in on time and/or budget.