> There’s a simple solution for today’s requirement, and there’s a complicated solution that will also solve a future, not existing yet, requirement.

There are tons of examples that show that your reasoning is incorrect.

Let's invent one: you need to build a car. Day 1: put the front left wheel on the frame structure. Day 2: put the front right wheel on the frame structure, Day 3: put the back left wheel on the frame structure, Day 4: put the back right wheel on the frame structure, Day 5: attach that particular motor on the frame.

Now, you are on Day 1, and Chet arrive and say "this wheel will not do, it will never support the motor that we need to install on day 5".

You are telling me that what Chet said is to be ignored because "it is a requirement for day 5". But it is not. What Chet has done is not bringing a requirement of day 5 into day 1, what Chet has done is that it has noticed an incorrect interpretation in Day 1 requirement. The requirement for Day 1 should have been read as "put the front left wheel on the frame structure, but of course, it goes without saying, use a wheel that is compatible with the car we want to build".

You saying that because Chet is using Day 5 information, the point he is making is not about Day 1 requirement is incorrect.

The thing is: Day 1 requirement and Day 5 requirement don't live on their own. Hell, your job is not to "just do Day 1 requirement" and it has never been. No one, absolutely no one, want a frame structure with just one wheel and no motor.

In the article, Chet does that: he tries to send the message "this is the point of the work, we will need it, it is what we plan to build, so you need to take that into account in today's requirement interpretation. If you don't account for it, you better not even do today's requirement".

And, and let me be clear on that, maybe the element that Chet brings will end up being not relevant or not needed. But the problem is that neither you or the author know that yet, and you reject the discussion before you can even discover if it's the case or not. The problem is that author and you just saw "Day 5" or "in 3 weeks" and, because YAGNI is a terrible advance, jumped on the conclusion "it is in the future, so it has nothing today with today's requirements".

(oh, and in practice, the people who says "YAGNI" will then say "well, the problem is Day 1 requirement, each requirement should go into excruciating details to re-explain the whole point of the work, should think of all the possible interpretation and should be written by someone who know better than me how to build the implementation to each line of code, but somehow should waste their time explaining the project to someone less competent".

Again, the problem with this argument is that the solution of "use your brain, build things carefully" creates a way easier and elegant solution than YAGNI+ridiculously unrealistic requirements.)