[skydhash]

> According to you "I could do this simplistic thing now but it would not work" is an impossible sentence?

Because that’s not what it said. If someone is talking to me, I don’t invent sentences in my head for them and assume things that they haven’t said.

That’s what you’re doing, inventing a whole situation outside of what the author described because you keep adding things that the author has not mentioned.

I have my interpretation of the dialog. And I agree with the author that Chet should focus on the simple thing now, and je can always wait later to refactor it to handle the future situation.

If you want to discuss an alternate interpretation, do it within the confine of the dialog. Don’t add your own words to it.

[cauch]

> Because that’s not what it said.

What it said is "I could do this simplistic thing now but ... that will be insufficient"

It LITERALLY says that it will not work, that it is not a good solution.

Even if Chet is wrong in his prediction, you quoted Chet and pretended that this thing that Chet is saying is a proof that this solution will work. This is so obviously not at all Chet's opinion.

And I'm sure you are going to INVENT "but Chet does not know what will happen in 3 weeks". Firstly, again, your "proof" is a quote from Chet, who, according to you, demonstrate that this solution is ok while that sentence is used by Chet to explain that the solution is not ok. But secondly, you have no idea why Chet is saying what he is saying, you INVENT that Chet does not know, does not have facts and numbers, while there are tons of real life example where it is easy and correct to predict that in 3 weeks something will not work anymore.

> ... inventing a whole situation outside of what the author described ...

I don't.

In the situation described by the author, is it true, is it factual that Chet thinks it will not work: YES, he is saying exactly that.

Is it factual that Chet is trying to provide more information but the author shut him down before hearing them: YES, this is factual.

Your only little argument is "let's imagine that Chet proposal, that he NEVER explains because he is interrupted, is bad". All I'm saying is that you have no idea what Chet argument is, you just assumed. This is fact. Can you tell me where, factually, in the written dialog, Chet explain his understanding and this understanding is indeed incorrect? Can you point me to these sentences? They don't exist.

You see "3 weeks" and concluded that "it is out of scope and/or over-engineered", which is obviously a bad conclusion as it is very easy to find plenty of example where this conclusion is totally wrong.

I don't want an alternate interpretation, there is no need for it. Does the author shut Chet down before Chet explains himself? YES. There is nothing to interpret, it's just a fact. Then, based on that, you said things that are BS, such as "Chet said '3 weeks' so it is the proof that it is out-of-scope". I then gave you a counter-example showing that your reasoning is wrong, and your only argument was "you invented this example so it does not count".

[skydhash]

> What it said is "I could do this simplistic thing now but ... that will be insufficient"

> It LITERALLY says that it will not work, that it is not a good solution

You have a strange definition of insufficient.

> Can you tell me where, factually, in the written dialog, Chet explain his understanding and this understanding is indeed incorrect

Both the author and I never said that the complicated thing is wrong or incorrect. YAGNI is basically saying “not now”. Meaning we can revisit when the situation calls for it, but not today.

YAGNI is a matter of priority and resources allocation. You don’t solve problems you don’t have or unlikely risks.

Do you set up a cold room in your house and buy food for the next month because you know you will be hungry then? No. You buy a fridge and groceries for the next few days. Not because a catastrophic event can’t happen, but because your budget is limited and/or you have better things to do with that money.

Complicated things cost more than simple things (to build and maintain) and take longer to ship and produce value. The only reason to not go with simple thing is when it does not work, not when it’s insufficient. We already know it does not handle every little feature, but it will work for now.

[cauch]

> You have a strange definition of insufficient.

You have a strange definition of "okay". "Insufficient" is definitively not okay. The definition of "insufficient" is "less than needed". How is that "okay"? And if it is not "okay", than, yes, it is not a good solution.

Thank you to demonstrate that people who pushes for YAGNI are delivering "insufficient" work and think it is "okay".

> Both the author and I never said that the complicated thing is wrong or incorrect. YAGNI is basically saying “not now”. Meaning we can revisit when the situation calls for it, but not today.

And you have no idea if the situation calls for avoiding the problem today or not today. Take back the car example: if you install wheels that are incompatible with the planned engine, you need to fix this problem __today__.

Your code will fail in 3 week because of a mistake you are making TODAY. The proof: if you install the correct wheels today, then nothing will fail in 3 weeks. The failure that will happen in 3 weeks (and it will happen: car engineers have tested it and are clear on that, it is the law of physics) is not due to a problem that was born in 3 weeks, the failure will be due to the bad decision made today. This is a TODAY problem.

Your reasoning is totally crazy, imagine if it was considered seriously: "oh, you noticed a bug in my code during code review. Well, let's ship the code in production and wait for users to raise a bug ticket, because before then, the problem does not exist".

> YAGNI is a matter of priority and resources allocation. You don’t solve problems you don’t have or unlikely risks.

And in the case of Chet, you have prioritized NOTHING. You still have no idea of what Chet was raising. You have no idea of what are the risks. You have no idea if your current plan is even the correct plan or not.

Imagine the following situation: "oh, we took the wrong road, if we continue tomorrow we will arrive in Berlin instead of Paris". Only very stupid people will say "no, that's a problem for tomorrow, let's just spend all the time in between doing something totally useless that we will need to undo tomorrow".

> You buy a fridge and groceries for the next few days.

You realise your contradiction here: you are saying you buy TODAY food for when you will be hungry IN THE NEXT FEW DAYS. According to your logic, you should not do that. What you should do is to go to the shop every single time you feel hungry and buy only one item, the one you want to eat now.

> Complicated things cost more than simple things (to build and maintain) and take longer to ship and produce value. The only reason to not go with simple thing is when it does not work, not when it’s insufficient.

Simple things that have no value at all cost more than complicated things. When Chet come up, he is saying "hey, I think I notice we are planning to build something that has absolutely no value". Your reaction is "no, it is better to do something useless with no value than something more complicated that has value".

And again, as I guess you will not get it: maybe Chet is wrong. The problem is that you just ignore Chet. Maybe he is wrong, but maybe he is right, you have absolutely not idea.

> We already know it does not handle every little feature, but it will work for now.

It will not work for now. If you install the wrong wheels on a car, the car is useless until you install the engine.

The important thing is not "the task of today", it is to deliver what the user needs. Here, Chet is saying that he thinks you are planning to build something that is a waste of time, something that will not deliver what the users need.

The reaction should be "Chet, maybe you are right, but maybe you are wrong, let's check together". Instead, the reaction was to interrupt him and act as if the users care about today's work more than the real product.

[skydhash]

The whole car example is flawed because insufficient does not mean wrong or incorrect.

> And in the case of Chet, you have prioritized NOTHING. You still have no idea of what Chet was raising. You have no idea of what are the risks. You have no idea if your current plan is even the correct plan or not.

Why are you so sure the author cannot compare <complicated thing> and <simple thing>? Or he has not considered <complicated thing> before even Chet and discarded it?

> When Chet come up, he is saying "hey, I think I notice we are planning to build something that has absolutely no value"

You’re again inventing stuff. The simple thing has value today. It will be insufficient in three weeks. It is not insufficient today. If we implement it, the user will have a working solution way sooner instead of waiting for the complicated thing to be ready.

How do you value your user’s time?

> The important thing is not "the task of today", it is to deliver what the user needs.

What the user needs today and what it will need in three weeks are different things. You and Chet have been ignoring the user’s need for today.

If someone wants some data outside of a system and you can write a quick perl script in 30 minutes to produce a CSV, you do it. You don’t argue about setting up a whole ETL pipeline because that will be needed in 3 weeks and the perl script is insufficient. Especially when that pipeline will take days to implement. You can have a whole set of examples and what not. But we can discuss that after the perl script is written and the needed data is exported.

[cauch]

> The whole car example is flawed because insufficient does not mean wrong or incorrect.

In the car example, the solution proposed by the team leader is insufficient. The result is that the solution proposed by the team leader will lead to either the project to fail or to a waste of money.

> Why are you so sure the author cannot compare <complicated thing> and <simple thing>?

What are you talking about? I'm not saying you cannot compare <complicated thing> and <simple thing>, I'm saying that the author does NOT COMPARISON: he has no idea what Chet is talking about, because Chet want to explain and the author shut him down.

You cannot say that Chet's solution, which is more complicated, is less valuable than the simple solution, because you don't even know if the simple solution has any value.

> The simple thing has value today.

No, YOU DON'T KNOW THAT. You invent that. Take the car example: having a wheel but no engine has no value. There are ton of other examples: for example, if someone is talking about a bug that occur because in three weeks we are in 2026 and that the code has a bug that make the code unusable if the year is 2026. If the product is released in February 2026, then the simple thing has zero value. (that's a made-up example for the sake of simplicity, but having bad design that destroy the quality soon after is a real thing, very common)

> How do you value your user’s time?

And how do you value users leaving because in 3 weeks that see the product is not able to do something they were expecting?

> What the user needs today and what it will need in three weeks are different things.

You don't know that. In the example of the car, the user don't need a 1 wheel car with no engine.

Again, because you have no idea what Chet is talking about, you have no idea if what Chet is talking about impacts today's users.

> blablabla ETL blablabla

You keep giving example where someone over-engineer (or ask for working on something too early, or ask to work on something out of scope, or ask to adapt the current goal based on hypothetical future goal, ...). EVERYONE HERE agrees that this is bad and should be avoided. The disagreement is that in the dialog in the article, the author did a terrible job at assessing if Chet contribution was a good or a bad thing (based on these criteria), because the author has drunk the YAGNI cool-aid and jumped to the conclusion it was a bad thing while there are plenty of situations where Chet will act exactly like that when it is not some of these bad things.

(and again, my criticism is not these "bad" things are not bad and should not be avoided, my criticism is that some devs say "YAGNI" and shut down the contributions that are fully relevant to do a good job and deliver value. A simple solution is to not be an obnoxious d*khead and just listen to Chet, to check if it is a real bad thing or not, and act accordingly like an adult instead of behaving like a little kid)

PS: I note that you just ignore elements where you cannot answer. (for example, the food that you don't buy one item at the time, the fact that "prioritization" means nothing when you don't even know between what and what you are prioritizing, ...)

[skydhash]

> In the car example, the solution proposed by the team leader is insufficient

Because you created that situation out of the blue. And you’ve been ignoring any case where both solutions do work, but one is more complicated than the other. And the simple one can be delivered very soon, but the complicated one will be useful only three weeks later,

> if someone is talking about a bug that occur because in three weeks we are in 2026 and that the code has a bug that make the code unusable if the year is 2026. If the product is released in February 2026

But the simple thing can let us deploy in 2025 and land a big contract before the holidays. Perfect is the enemy of good as we say.

> Again, because you have no idea what Chet is talking about, you have no idea if what Chet is talking about impacts today's users

It is explicitly mentioned that the complicated thing will only matter in 3 weeks, not today.

> You keep giving example where someone over-engineer. EVERYONE HERE agrees that over-engineering is bad and should be avoid.

And you keep ignoring that time matters and a problem in the future doesn’t mean it exists right now. You do the thing that matters for today, then you do the thing that matters for next week.

Your argument has been the thing that matters for today may not really matter and that is not what Chet has been saying.

  I could do this simplistic thing now but in 3 weeks that will be insufficient

Insufficient in 3 weeks only matters if we can’t ship the simple thing in that timeframe. If we can do so in one or 2 days, we can then focus on the complicated thing.

And that’s assuming Chet knows more about the project constraint than the project leader. Something my be great technically, but the other perspectives that the leader have is why he is refuting it. Like he got an email this morning that we will be abandoning the project in 3 weeks but we’re contractually obligated to fix every bug. He can’t discuss that with you, but he can direct your workflow.

So the next time you hear YAGNI, ask why. Don’t rush to prove your point.