The cost YAGNI was never about

> It only makes backwards compatible deployments easier insofar you're able to do the overhead for splitting the change with less effort then before.

Yes. That reduces the cost of implementing them.

To be clear, I'm not talking about "Split my db migration and my code that depends on the new table". I'm talking about things like "Set up dual writes between an old database schema and a new database schema with a thorough test suite and do shadow reads against both datasets in prod to do differential testing". That's nontrivial engineering effort that would definitely warrant a discussion in the past. Today we just do it. It's fast and lowers risk.

The complicated solution is trying to solve two problems at once, and one of them does not exist yet. It’s speculative.

> The fact that the author just chooses to not even try to check if Chet is correct or not should be a red flag.

Chet himself says that the thing will be necessary 3 weeks from now, implying that it’s not necessary today.

You can anticipate changes and plan for it. You can brainstorm it. You can even question the current requirements. What you don’t do is solving something that does not exist.

When we say YAGNI, that means the problem you’re stating, even when reasonable by itself, does not apply to the current context. It’s easier to revise a simple design later when needed, than refactoring a complex one that have a flawed assumption.

And the other axis is the lean towards complexity.

Let’s say you need to add logging for a web app to be able to quickly troubleshoot it. The design was to create a simple module that printf to stderr. But then the dev comes to you with a new complicated design involving elastic search and what not, saying that we will need it in 3 weeks to dissect the logs, etc. It may have been a good idea, but it’s not valuable. The correct idea is to put that on the backlog, not to start writing code for it.

Implementing complicated idea takes more time than implementing simple idea, while the value is the same.

When there’s a need for having something elastic search for the logs, it will be easy to refactor the simple code that we have than fixing the possibly flawed implementation that would have resulted if we went with the complex design.

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.)

In your example, the general goal could be to do a small sedan car, but then Chet come in and say that we need a more powerful engine as the user may like to go offroad with a trailer. And he’s ready to cancel the order for the standard engine and ready to adjust the chassis, the frame,… for the new engine.

But the thing is that there is no such requirement in the design, no hard data that says that user would like such data. It’s just anticipating needs without proper market research.

And as I’ve said previously, it’s okay to explore design for a more complete solution. It’s not okay to commit to them with just an emphasis on the benefits, nit the cost of maintenance while there’s no value to the business.