That´s why I prefer YAGNIN instead:
You Ain´t Gonna Need It NOW, meaning that one should think ahead about future use cases and extensions, but resist to put more than just basic work in it.
Practical examples:

-if there are multiple ways on solving a problem prefer the ones which allow for easier extensibility, modification and reusability

-edge cases which do not show up now but possibly in the future need not be solved instantly: A placeholder (e.g., an info message for the user/supporters/testers and/or a comment for the developers) serves best here as it allows considering this part as ‘done’ while still serving as a starting point in case it will be needed somewhere in the future

-often there are already ideas about how the not-yet-needed stuff would look like: Writing it down in a separate part of the design documentation or as comments within the implementation not only helps in case when it will be actually needed it also helps in understanding the the already-in-use stuff was created the way it is

-generally, viewing the current task from a big picture view also helps in deciding which future requirements are likely and which should be solved elsewhere: Would they be helpful for smooth integration and user experience? Or would they just look like an ugly extension messing up the overall result?

-if it is unknown how future demand will look like it is best to start with a simple “quick and dirty” solution. It is still good enough for learning from its first results and, once the right pattern gets more visibly, can be thrown away in order to be replaced by a more sophisticated one (Yes, throwing stuff away is an important YAGNIN principle: Trying to be overly smart for the first time usually doesn´t work out that well, but not doing it at all is hazardous as well. One needs to know when the time is right for putting it up “the right way”, otherwise you´re wasting time for an either unnecessary or inadequate implementation.

Thinking YAGNIN style is especially helpful when designing interfaces: Even poorly designed ones tend to last almost forever and thus create a lot of damage since effort required for bypassing its limitations quickly surpasses the time saved for not thinking about it at the first time.

The most interesting part of my YAGNIN experience is that although only just half of the stuff I considered for future use actually gets used later on, however the decisions made for them often turns out to be helpful for upcoming requirements I haven´t even thought of back then!

Acronyms such as YAGNI have their uses but the danger is an oversimplification that blinds us to the individuality of situations. For example, DRY and YAGNI can conflict in situations where your instinct is to stepback and solve the general case.

In the same way, sometimes it’s easier to create a more general solution than the immediate problem requires.

However, how many of us are really so smart that we can be rock-solid confident that we’re not going to need some functionality – and need it in a hurry? Surely we’ve all experienced the distressing realization that some early decisions to eschew generalization were, in hindsight, unfortunate.

I think that, in the end, “rules” like YAGNI are just fingers pointing at the moon. A skilled, wise designer/developer will have a good instinct to judge the difference between components and facilities that are pointless fluff (or, worse, boat anchors) and those that are valuable nuggets to be tucked away for emergencies down the road.

So YAGNI should be applied on all levels.

YAGNI is a factor that only becomes measurable after the fact, and in some cases even years later. How far to go to “defend” the code against possible future changes is largely guesswork. The reason why we as programmers have a strong tendency to err on the wrong side, as in writing too much code, is because we’re optimists: we always want to believe this one is the one that’s going to last, that’s going to be so successful it will be maintained and extended for years to come, well beyond the original, (in our eyes) limited vision of our employer/client.

And we have to be. Because no matter how much we all know it to be true, facing the reality that most of the code we write will never again be looked at by another human being, and most of it won’t even be in existence in a few years time is just way to depressing….

Anyway, determining where the YAGNI limit lies is not something that should be left to the programmer in “deep coding mode”. Ideally, it should be a joint effort. It’s always much easier to spot when someone else is overdoing it.