Quite a contrived scenario, but, no. Just build the feature you need and move on. No need over-analyzing.

See? I didn't have to get trapped in your pretty much un-answerable pondering.

Following the rule crystallizes a lot of decision-making. It's very empowering when you don't have too many objectors.

And yet, you might take longer to finish the project than someone else. Just because something is freeing doesn't mean it's a good idea. Nor does it mean it is a bad idea, it just means it's an uninformed idea.

Obviously it's suboptimal to ponder an un-answerable question. That doesn't mean it you shouldn't spend 1 minute thinking about it.

First, let's disabuse you of the notion that you "know" anything about the future. You can only guess about the future.

Then you need better management on your development team. A project manager who can't give at least an intelligent assessment of the risk/likelihood of key features changing some way ahead is about as useful to a programmer as a programmer who can't give an estimate of how long it will take to implement a simple feature within an order of magnitude to a project manager.

I am still waiting to encounter this hypothetical project where the future always deviates significantly from any reasonable prediction with negligible overhead. On the contrary, my experience has been that any successful project team probably has at least a reasonable idea of where the development is going some way ahead and that confidence usually increases the closer you get. While that level of confidence may not justify immediate full development of future features that aren't 100% known to be required, it does often let you make reasonable allowances for likely future work in terms of project architecture so you don't back yourself into a corner unnecessarily.

As chris_va has been saying, it always comes down to risks and confidence and cost/benefit analysis, like any business decision. You can repeat "You ain't gonna need it" until you're blue in the face, but that doesn't make it true. Much of the time, you will in reality need a feature that everyone has been talking about for six months already and your sales guys have been promising to customers for seven of them. In fact, any development team that really does dwell extensively on development work they aren't actually going to need later should probably question the general competence of their management. Responding effectively to changing requirements does not require sticking your head in the sand, and it certainly doesn't require making ad-hoc changes to design/architecture at any level you feel like for every new feature.

It's possible you have worked in a world where there really is requirements-level (which means business-process level) stability over a year. I never have, and I don't think that describes most businesses out there.

Given that, writing software that is responsive to the needs of the business must accept that change in unknown directions is a certainty.

Now, does that mean that you literally never know anything at all about what will come up? No, of course not. Sometimes you'll see a thing coming for nine months, and it'll actually land just like everyone thought.

But the point of YAGNI -- and the point Fowler made so well in his essay -- is that you still don't need to do your chin-stroking calculations and elaborate plannings on whether you should build for that now. Because building for it now has a real guaranteed cost (the direct cost of building it, the opportunity cost of the value you didn't deliver by building something more immediately necessary, the technical debt of maintaining it in the face of other evolution until you get to the time when it actually is needed) that strongly argues against building it even if it will happen.

In any other field, this is really obvious. If a contractor is building a house, and they say "you know, we've already got the cement-pouring team here, we know we're going to build a dozen houses this year, why don't we just build all twelve basements right now" they're going to be slapped down quickly -- that's absurd, don't tie-down all those resources speculatively, and anyway if you do that, the house you're building is going to be late, let's focus on what's needed. And that's true even if the contractor was totally right about needing those dozen houses (and exactly which dozen, and exactly what they should look like).

That you're probably going to be wrong to one degree or another (even features that end up happening often look significantly different when they happen than they did in prospect, months out) makes the YAGNI equation that much more compelling; but even without that, the numbers rarely are going to come down in favor of speculative construction for hypotheticals.

So, yes, you need to weigh the benefits against the costs. It just turns out that this is nearly always a calculation that leads inexorably to one result: Don't do it until you actually need to do it.

I think the difference between the pro-YAGNI crowd and the sceptics here is one of absolutism.

You have immediately translated my position, which was about risk and confidence and making a cost/benefit judgement based on the best information at any given time, into an absolute one, where we know the full requirements for a project a year in advance. But that isn't what I said, or what several of the other sceptics here are saying either.

To put it in your terms, we're not saying you should build 11 spare basements because you've got the concrete guys on-site today. We're saying if you're building a concrete basement then you can reasonably assume this house will also soon have external walls that will roughly match the signed-off, legally-binding planning consent, so if you don't put the rebar in before the concrete sets you're going to have a much harder time finishing the house later or may even find it is no longer cost-effective to do so because the cost of doing that preparatory work only when you're certain you need it will be very much higher.

Except it turns out that:

a) The boss has changed his mind and now we're building a pool, so we need to cut off all this f* rebar sticking out. More time to remove it, plus the cost of adding it in the first place. b) Its software, so adding the rebar is as easy as F6-refactor.

You are scaring the children. Stop it with the FUD.

You can always come up with exceptional counter-examples in any argument about probabilities and making cost/benefit judgements. As I noted elsewhere, my experience has apparently been very different to some here, because I'm still waiting to see the project where the entire direction suddenly shifted so fundamentally that it wound up writing off significant amounts of code that was now useless. (Just for the record, I'm also still waiting to see the house where the rebar is in changed to require a pool where the planning consent stated a house was to be built, though I've seen a lot of houses with the rebar in where the walls then went up a short time later without having to rebuild the entire foundation because the rebar was already in.)

I've written elsewhere in this HN discussion about a few different types of project where you can't just refactor your way out of trouble if you go too far down the wrong path. The cost of doing so can easily become more expensive than just throwing out the whole thing and starting again.

This isn't FUD, it's a few decades of professional programming experience talking. They just happen not to be the same few decades that some of the other posters here have had. And as once again I seem to keep writing now, that is why it is unwise to generalise too far from personal experience or a small anecdotal base to an entire field as vast as programming.

The examples given are always so contrived.

And the whole point is to eliminate all this clutter from your head so you can focus on the task at hand.

I don't find having varying levels of data and confidence about the likely future directions of a project to be "clutter", nor do I find they tend to complicate whatever I'm trying to develop right now. On the contrary, I often find it useful to have more context and frame of reference about what I'm doing, even though often I may choose not to act on that knowledge immediately for much the same reasons that others here are arguing for always following YAGNI.

Please remember that my argument is not that you should always try to anticipate future requirements or over-engineer designs to cope with every hypothetical you can think of. My position is merely that you should weigh the costs of acting unnecessarily now against the costs of not having acted when it turned out to be useful, and make a decision according to your best estimate of how likely it is that you will benefit from following either path.

YMMV, of course, and certainly sometimes the decision will be different to others.

In principle I'd agree. In practice, I think people consistently overestimate the value of planning, and my experience is so overwhelmingly in favour of not planning that I don't think it's worth spending even a small amount of time (which is a nonzero cost) trying to calculate whether this is one of the one-in-a-million cases where it would be worthwhile.

If I had one hour to save the world, I would spend 55 minutes defining the problem and only five minutes finding the solution. –Einstein, Albert