The cost YAGNI was never about

> And if you have to always explain what "Real" Blub is and how almost no one practices Real Blub, then maybe Blub was just never a good maxim to begin with.

I'll push back.

No-one I work with seems to practice "real DI", "real encapsulation", or "real agile", and the software is the worse for it.

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

This is the problem: your judgement is biased. You think it was a good idea, but in reality, you have no real idea if it was or not.

Don't get me wrong, as I've said, I think that sometimes not over-building is a good idea. The problem is that YAGNI is the wrong solution. To avoid over-building, the solution is not to invent a rule that says "just don't build". The solution is to stop having developers thinking they know what is useful or what is not.

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

Again, you cannot know if it is worse or not. You are not the user. It may be good in some cases, it may be bad in other, and I have seen devs saying exactly what you said when their "abstractions in hindsight" was catastrophic.

There is a lot of example, but just one: we built a system that was collecting data, the goal being to accumulate data for months and then analyse it. Few people involved in the project proposed some structure for the data, but the devs used YAGNI to do what they preferred (there was some objection but at the end, the devs just did what they wanted to do, ignoring the rest of the team because they were confident that they knew more than them how to build software). Later, we started the analysis, and realised all the data were crap: the devs kept changing the data structure by building their abstraction with hindsight, without even documenting when these modifications were deployed to the different sensors. We had a mix of data built based on different parameters with no way to know which part was using which parameters.

After the project failure, I saw many devs still saying that they were right to use YAGNI, and being totally oblivious that it's their choice that doomed the project. They were, seriously, saying that it was a lack of requirement, or that the "users changed their mind", while it was not true at all (I was there, and I was not in either side, I just observed), the situation was well known from the start. The problem was they insisted to apply YAGNI as if they understood better than the other collaborators what as needed.

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

You literally just said "ive always noticed that abstractions which are front loaded are nearly ALWAYS worse than abstractions built with hindsight".

This is literally you remembering the amount of "win" and the amount of "loose".

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

That's exactly my point (and I'm not a dev).

When you are saying "abstraction is better built in hindsight", you are just thinking you are smarter than other people.

When the situation is that it is difficult to understand what we will need, the solution is to discuss together to understand what we will need. We may get it wrong sometimes, but we will get it right sometimes. If someone just decides to ignore other collaborators opinion and decides "we will need this abstraction", this person has way more chance to be wrong. If someone just decides to ignore other collaborators opinion and decides "we will not need this abstraction", this person has way more chance to be wrong too.

YAGNI is just someone noticing that building a big house without following the plan led to extra work because they have to demolish the bits they've built on next door property, so they decide to build a small house without following the plan.

Over the last couple months I've seen the debt multiplication in some OSS projects. It's like premature aging of a codebase.

Citation needed.

But in seriousness, this intuitively feels like something (as phrased) that would be easily influenced by loud noise and quantity rather than hard facts. The "piloted poorly" part is applicable to any tool use. AI is no different there other than its adoption rate.

> Kent Beck compares unwritten code with a financial option to buy something at a given price.

From Kent's "Tidy, First?"

  Software creates value in two ways:
    What it does today
    The possibility of new things we can make it do tomorrow

Unwritten code has no value. The code that is being written today, if it will be creating value, leans towards helping with with a request/issue today or helping making/solving things easier tomorrow.

Then there's the various way of not creating value or favoring one of the two aboves. Either by taking on tech debt with hackish solutions or wasting time with YAGNI stuff.

> If you haven't written any code, do you have infinite options?

So it's not about unwritten code, it's about the code that you're going to write and it's purpose. And the correct tradeoffs between resolving the ticket/todo and not shooting your future self's foot.

Writing code is commitment. And while the value for today is visible (either it's useful or it's not), the value for tomorrow is guesswork. But there's always some cost to be paid for later, so you guess in order to keep the cost minimal by anticipating what will be required.