[cauch]

I agree.

Nothing is all black or white of course, but I have personally observed situations where software engineers started with YAGNI and then said "that will require too much restructuring, we went into another direction, so, no, we cannot do it anymore". The worst part is that software engineers are not even in a good position to understand when YAGNI fails: when they don't plan for a useful feature, the solution is often for the users to just shrug it off and use a suboptimal solution rather than fighting and dying on a hill that they cannot win (at the end, the software developers can just say "nope, it's technically impossible" even if it was possible, they have a huge advantage). I also saw users just assuming there were good reasons why the feature did not exist ("well, I guess if they did not did it, it's technically impossible") and just don't even say it. And as the developers are not the users, they never notice anything.

100% with the way of illustrating: YAGNI is "we are consultants in a field we don't understand": sometimes, users are asking for too much, sometimes, they are asking for something reasoning, and the developers have no experience to distinguish between the two.

[MoreQARespect]

YAGNI is simply a tacit recognition that you can't predict the future with any reasonable level of certainty. The reason it is controversial is that some devs truly believe that they can predict the future with all the self assurance of a grandma sitting in front of a one armed bandit in vegas. So, they will:

* Create generalized functions where a specific one would have done.

* Create abstractions for something that will never be needed in the end.

* Create abstractions for something that will be needed but not in the form they initially expected.

It is not about avoiding refactoring. That misses the point entirely. Refactoring cleans up code mess that exists NOW - creating abstractions for somehting that exists NOW.

[cauch]

The problem is that YAGNI is __literally__ predicting the future: you ain't gonna need it.

How do they know that, if it is not a prediction?

In the examples I have observed, your 3 points were made impossible because early on people said YAGNI. You can always "create them later", the same way you can always "restart from scratch". Creating abstraction for a code that was designed without being compatible with these abstraction has a huge cost. And, as I've said, it is not rare that it's the users who pay the most of the cost, which mean the devs don't even know it is a problem.

As I've said, nothing is all white or all black. The problem with YAGNI is the developers think it's all white: they can decide "you ain't gonna need it" when they have no expertise on what is going to be needed because they are not the users.

[MoreQARespect]

It's predicting that you will predict wrong frequently enough to make it not worthwhile predicting at all.

I apply the same logic at slots: the way to win is not to play.

>Creating abstraction for a code that was designed without being compatible with these abstraction has a huge cost

I have never found it more expensive to create an abstraction after following the rule of 3.

Indeed, ive always noticed that abstractions which are front loaded are nearly ALWAYS worse than abstractions built with hindsight.

>As I've said, nothing is all white or all black. The problem with YAGNI is the developers think it's all white

We think you're playing slots and remembering only the wins, believing that you're just naturally talented at predicting the future.

Ive seen this attitude in hundreds of devs. They all think theyre uniquely able to anticipate the code base's future needs.