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

[cauch]

What you say if not making much sense. You don't provide counter-arguments or arguments, it looks more like a collection of special cases, but they don't contradict anything I'm saying. It's like if I say "f(x) = x - 10 can be negative, for example if x = 2" and you just say "no because sometimes x = 15". I don't get the point of your argument, you seems to say that if you find one special case that works for your conclusion, then your conclusion is correct.

For example, you just say "what if the simple thing can let us deploy in 2025 and land a big contract before the holiday". Firstly, it's a weak example, do you really believe that someone will sign a big contract with you on brand new code within 3 weeks of the release without either testing for few weeks or asking guarantee that it will still work after 3 weeks? Secondly, it's easily a bad point for your approach, what do you think will be the commercial impact when the partner will see that your code falls apart after 3 weeks because you did not anticipated something they find obvious? Thirdly, a simple tweak and it becomes an example against your approach, what if the big contract is on week 4, and that you miss it because you have to undo the simple solution and build the more complicated solution in order to have a product that work? But more importantly, it does not contradict anything I said, my approach still is better: if you have a big contract, then LISTEN TO CHET, and if what he says can wait, just say "great, noted, but we will do it after the big contract" (and if Chet has a good point, you will win bigger).

I really don't understand your point: listening to Chet has only good consequences. You listen to him, and then you still can decide if it's smarter to do it now or not.

For all the scenarios that me and you have proposed, your method keep failing my scenarios, while my method keep succeeding my scenarios AND your scenarios.

You also are hypocritical: on one hand, you hand-wave "perfect is the enemy of good" and on the other, you whine "bouhou, if we try to stay aware of the constraints that are coming our way, this is soooo baaad, we need to stay pure and perfect, this is sooo important".

About "today's user": users don't care about the code. If the plan is to work on the backend on day X and on the front-end on day X+3weeks, the fact that the code runs on day X is a negative for the user, today's user, because today's user cannot use the backend, he needs the backend and the frontend. And because you built a backend incompatible with the front-end, you will deliver even later. Another illustration is about the car example: today's user don't care about a one wheel structure without an engine, this is totally useless for them. If you successfully install the wrong wheel today, you impacted negatively today's users, because they will get their car even later.

About "time matters": you are arguing that, but you are pushing for a solution that WASTES time. Your logic is "installing the wrong wheel takes 5h, installing the correct wheel takes 10h, so let's install the wrong wheel". Except that the user will not be able to use the final product until the correct wheel has been installed, so you will use 5h to install the wrong wheel, 5h to uninstall the wrong wheel, 10h to install the correct wheel, and you will have spent 20h instead of 10h. And I know your argument, which is "I'm not talking about the car example, in my scenario, today's task is a feature that users can use directly". But my argument is that you are shit at knowing if it is the case or not. You read this article, you saw the author shutting down Chet, and not one instant you thought "ok, but of course this is terrible advise if we are in a car-example situation". I looks like this possibility flew high above your head, as I need hours of exchange to educate you on the subject.

About "you keep ignoring that ... a problem in the future doesn’t mean it exists right now": You saw "3 weeks", and you are mentally unable to realise that because the code is running today, it does not mean that the code is delivering what it is supposed to deliver. A simple example: the task is to install wheels that are compatible with the planned engine, and the team leader planned to install the wrong wheel. Someone notices and say "in 3 weeks, when we install the engine, it will not work". This is not a future problem: you have failed TODAY'S REQUIREMENT, TODAY'S TASK. The task itself requires that what you build is compatible with what will be built in 3 weeks. But because you saw "it will not work in 3 weeks", then you concluded that what you have built today satisfies the requirements. It is sometimes the case, it is sometimes not the case. And because you did not let Chet talk, you don't know what he is talking about, so you don't know if he is talking about a future problem or you having failed today's task in a way that will only be visible in 3 weeks.

About "assuming Chet knows more about the project constraints than the project leader": YES. NO ONE. NO. ONE. No one knows the project perfectly. No one will never miss something. When Chet is coming to the team leader and says "I think we may be wrong", listen to Chet. If Chet is incorrect, fine, no harm done. But Chet may not be incorrect. The team leader does not know what they don't know, they should never assume that they know more about the project constraints than the other collaborators.

And again, because I'm sure you have difficulties wrapping your head around this: I don't ignore that not all project are like a car construction. The problem is that your arguments are incompatible with a common situation. The fact that your arguments are not incompatible with some situations does not mean they are correct. The fact that they fall apart in some situations means they are incorrect.

[skydhash]

Your argument is always about:

  We need to to task X today, we're going to do Task Y later. But we need both task X and task Y to complete the whole project. But the solution for task X is wrong because it conflicts with task Y. And when we get to task Y, we won't be able to deliver. And Chet know this. But the author don't want to listen to Chet, and the author is wrong for that.

While the situation is:

  The project is already defined. There's task X to be done, and we have settle on a solution A for it. Chet is the one who will be implementing it. Chet uncovers a situation that leads him to believe that the solution B is better because of a constraint that will come in effect in 3 weeks. He says that he can implement A, but because we're going to need B in 3 weeks, let's scrap A and go with B instead. Now the author knows both A and B (and maybe B was discussed beforehand but Chet don't knows about it),and says that B don't matter, A is good enough.

  Instead of asking why, Chet decide to argue for the validity of B. The author reiterates that B doesn't matter. At the end Chet decides to walk away. And never wanted to learn why A is the better choice when B seems to be perfect.

I was Chet at one time and never have someone like the author to rein me in. I get cured from wanting to implement complicated solution when client asked me for demos and I couldn't show anything because I was trying to solve everything. And you're right, they don't care about code. They care about working product, and today, not in 3 weeks. So between A and B, I deliver A first, then worry about B.

And when someone higher than you (and better placed to have more information about the constraint of the project) refuses your idea. You ask why, you don't immediately try to prove your position. Imagine doing that in the army.

[cauch]

> While the situation is

BS. You have no idea if it is the case, you don't listen to Chet. You __assume__ that Chet's solution is motivated by a different goal, but you __shut him down before he said so__.

You now invent things that are never described in the scenario, to try to badly justify that somehow the author's ASSUMPTION is justified. But the problem is that even if what you said happened, the author's assumption is still an assumption: the author is a bad lead for not verifying at 100% that Chet is indeed talking about the same B that the author has in mind. And even if the author does it behind the scene, the author is a bad lead for not being fully aware that he should have writing this step explicitly within the scene, as it is a crucial step for the judgement and should be evaluated before acting as he did.

> Now the author knows both A and B

The author SHUT CHET DOWN BEFORE Chat explains what he is talking about. How does the author even know that Chet's complicated solution correspond to B?

I guess you will say "but Chet told him behind the scene" or a bad argument like that. Which is of course changing the scenario as described in the article (something you were incorrectly whining about but have no problem doing it yourself).

But also it justifies my criticism: even if Chet's explanation happened behind the scene, it means that when you read this scenario, instead of thinking "oh, red flag, the author should make sure he understands exactly what Chet is talking about", you just __jumped to the conclusion__ that this situation was a "constraint from a hypothetical future" situation where what you had behind your eyes gave you no indication it was. And you __invented__ without any justification, that elements that are not within the scene occurred just to justify a posteriori your conclusion.

To take a more extreme example: it is like if the article says "and then this black person is arrested", and when someone says "it is strange, I don't understand on which basis this person was arrested", and someone says "well, when reading the article, I just assumed that the black person is a thief and that they saw it behind the scene". This last person reading of the article has highlighted his prejudice, his bias. Same here: you ignored the possibility that it may be a "Task X vs task Y" situation because you __blindly assumed__ it is the situation that YAGNI has put in your head.

> and maybe B was discussed beforehand but Chet don't knows about it

And maybe the unicorns have whispered to the author's ear what Chet was talking about.

You are so full of shit, you are just making excuses and grasping straws to pretend that the terrible judgement of the author was somehow justified behind the scene. Do you even realise that?

> I was Chet at one time ...

I am not surprised at all. But the problem is that not everyone is as bad developer as you are: sometimes, they found __proper problem__. In the exact dialog, the author shuts Chet down before he can explain the problem. Chet even said "you don't understand ...", trying to say to the author that what he is bringing is not what the author seems to understand it is. That in itself should give you pause: "wait, are we sure Chet is not trying to talk about a problem that the author genuinely missed", but it did not because you were unable to mentally conceive it may be the case.

> And when someone higher than you (and better placed to have more information about the constraint of the project) refuses your idea. You ask why,

Again, if you are a team leader and you think that you will never miss anything or that you are the only ones in position to discover things that has been missed, then you are such a shit team leader. With a fragile ego.

> Imagine doing that in the army

WTF? What kind of argument is that? Your argument seems to boil down to "reSPecT my auTHorItaaa". As a team leader, I am smarter than that: I know that sometimes things will be missed, and I know that it is better for everyone to be in a situation where anyone can bring it to attention.

And, yes, sometimes they will bring to my attention things I already know. But I listen to them first. It does not change ABSOLUTELY ANYTHING, and if someone says the opposite, this person is full of shit and does not know what they are talking about.

[skydhash]

YAGNI means you ain’t gonna need it. And if you can’t ask why A stays and B can’t be accepted, that just means you believe your reasoning is always the correct one, and your team leader is an wrong to not accept it.

And as I’ve said. If you state something and the person in front doesn’t accept it, you ask for his reasons. You don’t rush to prove yours.

You really can’t accept that the author knows about B and have a valid reason to not choose it, evenk if B is completely valid? Software engineering is all about tradeoffs. And it’s on the leaders to choose some, even if you really believe it must lean the other way.

[cauch]

> And if you can’t ask why A stays and B can’t be accepted, that just means you believe your reasoning is always the correct one

What? Why are you saying "if you can't ask why"? I personally can ask "why", there is no problem with that. I have been in situation where I was the lead and I had to say no to someone like Chet and I've done it after listening to him. And I've been in situation where I was the lead and I listen to Chet and Chet had a good point that was useful, and I used this point to reassess my decision, and sometimes I change my plan, and sometimes I did not. And I've been in situation where I disagreed with the lead but said "ok, you're the lead, we should not flip-flop between captains, we need one person at the driving wheel, so I accept your decision". Why are you inventing that it is a problem to me? Can you provide the sentence I've written that led you to that conclusion?

But in the article, in the scenario, the author never ask "why". Chet arrived and said he thinks there is something suboptimal, and the author did not say "why", he said "YAGNI", and Chet tried to discuss this and the author did not say "why", he said "YAGNI", and Chet tried to have the author explain why, and the author did not say "why", he said "YAGNI".

The author __REFUSED__ the discussion. Chet did not even had the opportunity to say "why".

> If you state something and the person in front doesn’t accept it, you ask for his reasons.

It is what Chet is trying to do. Chet does not say "no, you are wrong", Chet tried to discuss this: he wants to explain his argument to know what are the author reason for possibly refusing. Chet suspects that the author does not understand, he tries to clarify, to give example, but the author just refuses.

> You really can’t accept that the author knows about B and have a valid reason to not choose it, evenk if B is completely valid?

Why are you thinking that? The problem is not that I believe the author is wrong about B. The problem is that the author has assumed Chet was talking about B when this is only an unsubstantiated assumption.

Look at what I've written, I've written explicitly:

> You listen to him, and then you still can decide if it's smarter to do it now or not.

If you decide "let's not do B" and Chet says "no, I refuse to accept that", then Chet is 100% wrong.

The problem is that the author decided that Chet was talking about B __before Chet even explain what he is talking about__.

Again, if the author has good reason to not do B, then, I FULLY AGREE WE SHOULD NOT DO B. The problem is that the author is an idiot: Chet tries to talk to him about something, and the author just assumes, without any proof, that it is about B.

> Software engineering is all about tradeoffs. And it’s on the leaders to choose some, even if you really believe it must lean the other way.

A leader that choose between tradeoffs when he __refused to listen to the information__ is a bad leader, and his work will be poor.

Let's take your logic further: why providing any information to the lead at all? The stakeholders approach the lead and say "hello, we would like to have a feature, this will be ...", lead: "STOP! This will be a frontend interface with an animation of a little frog dancing", stakeholders: "what? no, we would like ...", lead: "no, you want that", stakeholders: "but you don't understand ...", lead: "good meeting, byyyye".

Honestly, your position is so weak. My question is "what's the problem with just listening to Chet to understand what he is talking about", and your position is so poor that the only thing you were able to do is to say "no because if I listen to Chet, it means Chet refuses my decision", which is blatantly incorrect.