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

[skydhash]

Chet has already told the author about B in the first sentence (that’s how the author knows B is complicated). The rest is Chet trying to justify B without asking why the author choose A.

It’s not Chet explaining what B is, it’s Chet explaining why B is better. From his own point of view. With no understanding why the author prefers A.

Assuming the author don’t know anything about B and that it can’t understand the tradeoffs between A and B is where you are wrong. Especially if the tradeoffs lean strongly towards “shipping soon” and away from “Be correct 3 weeks later”. In that 3 weeks window, there will be time to review B while A is already providing value. But Chet’s decision to scrape A is not the correct one.

And about the taking the logic further, you’re again inventing a situation that the author has not been discussing about

> My question is "what's the problem with just listening to Chet to understand what he is talking about"

Because what Chet is talking about is abandonning A, a simple solution, for B, a complex one, where the primary reason is that B will be useful 3 weeks later. And for the author, that tradeoff is unacceptable. Why? Chet doesn’t know, because he’s too busy trying to prove B.

[cauch]

> Chet has already told the author about B in the first sentence

No. Chet says, I quote, "so since we’re going to need this more complicated thing I want to do it now". Chet does not explain what is this more complicated thing that he wants to do, what is the problem exactly, if it is a problem linked to A failing the requirements of today or not, ...

> It’s not Chet explaining what B is, it’s Chet explaining why B is better.

Ok, first, for the author to not be a shit team lead, he needs to understand B itself, but also how B fit into the picture.

(also, what is the problem with that: if Chet's opinion is that B is better, I __want__ to hear it. It does not mean I will agree. It does not mean Chet is right. But if someone reached a different conclusion than me, I need to understand why just to check if indeed I've missed something or not)

But secondly, that is again your bias talking. You are brainwashed by YAGNI, so when you read what Chet says, you are unable to imagine that the exact same conversation can happen if Chet is presenting a real new problem that the author missed.

That's my whole red flag with the article: it starts with this scenario, and then continue explaining YAGNI. The author explains YAGNI perfectly. But the big problem is that in his initial scenario, he is showing in fact a scenario I saw over and over again: he fails to notice that someone may say exactly the same thing as Chet __and yet__ "YAGNI" as he correctly describe it later does not apply. The author just teaches readers to be idiot, to not think, to just see someone saying "3 weeks" and then jumps into "YAGNI" without even checking if YAGNI applies or not.

> Assuming the author don’t know anything about B and that it can’t understand the tradeoffs between A and B is where you are wrong.

Read what you have just said and think about it. I am saying "everyone, sometimes, can miss something". And for some strange reason, you understand "this person know absolutely nothing".

I am saying that the author know a lot about the constraints of the project. But unless the author is an idiot, the author also knows that he may have missed something and that someone else may have noticed.

In this dialog, the author does not check if Chet has found something he has missed. He directly assumed Chet is wrong and he is right.

Why is Chet even in the company? You are saying that the author is god: he is never ever wrong, he knows everyyyyything, he is perfect. As soon as you admit that this is obviously bullshit, then you have to admit that the author should engage with Chet to check if something was missed. Again, taking the exact dialog of the article (as you whined about), looking it word-for-word, Chet did not explain his point and the author interrupted him before he could. You can INVENT that the author knows things behind the scene or that they said other things on top of what is written, but then not only you are hypocricital, but on top, it shows that both the author and you just took some hypothesis for granted: you are biased.

> Especially if ...

Again with "you gave a counter-example that shows I'm wrong, but let's ignore it and take an example I've built myself where it works".

Again, I'm saying: "the author is a poor lead because he did not check if Chet has found something he missed", and your answer is "but let's assume Chet did not found something he missed". But the problem is still there. A good bus driver looks both ways before crossing the busy road. "Let's assume no car was coming" means that this mistake, in this specific case, has no bad consequences, but the bus driver is still a terrible bus driver if he did not look both ways. Here, if we assume Chet did not notice something that the author missed, then the author has been lucky, but he still failed to do something he needed to do in order to be a good lead.

> And about the taking the logic further, ...

Do you even understand the principle of "taking the logic further"? Are you telling me that "to take the logic further", one should apply the same logic to THE SCENARIO THAT ALREADY EXIST? How is that moving it further?

Pushing the logic further demonstrates the flaw in the logic. If your logic was sound, than pushing this logic further would not create any absurd situation.

> Because what Chet is talking about is abandonning A, a simple solution, for B, a complex one, where the primary reason is that B will be useful 3 weeks later.

HOW DOES LISTEN CHANGE ANYTHING?

You just LISTEN. You don't say "tell me Chet, and once you told me, I will have no choice but to accept".

You LISTEN to Chet, and if Chet explains and you see that the trade-off is bad, YOU TELL HIM "WE WON'T DO THAT".

That's the problem: for some strange reason, you seems to believe that if Chet just tell you his reasoning, it means you agree with him. You don't have to agree with him, you just have to check if the reasoning of Chet is indeed the reasoning you assumed he had at the start when he did not explain his reasoning yet.

[skydhash]

> The author just teaches readers to be idiot, to not think, to just see someone saying "3 weeks" and then jumps into "YAGNI" without even checking if YAGNI applies or not.

If that’s your take away from the article, no wonder you’ve been trying to twist the dialog to justify it.

From the article

  YAGNI is not an excuse to never design as some critics have characterized it. If you need it, build it. YAGNI is a meditation on timing. Building structure too soon is as risky as building structure too late.

That’s why the author says YAGNI in the article. It’s not about never discussing B. It’s about shipping A before shipping B. especially when by shipping A, you can start providing value sooner.

> You don't say "tell me Chet, and once you told me, I will have no choice but to accept".

It’s Chet that refuses to accept that, from the author point of view, B isn’t better than A.

> That's the problem: for some strange reason, you seems to believe that if Chet just tell you his reasoning, it means you agree with him

That’s what YOU believe is the problem. Chet himself has said that B will matter in 3 weeks. He hasn’t said that B matters now.

The problem is clearly stated and argued in the article. It’s better to focus on the simple solution that solves current problems than trying to implement complex solution that solves future problems.

Do you agree or not with that statement?

[cauch]

As I've said (quote): "The author explains YAGNI perfectly".

My point is that he does not notice that he is doing, in the scenario, what he is saying should not be done.

What the author is doing is a common mistake with a lot of people into YAGNI: they just think that because they see "3 weeks", it means that the problem is not about you failing TODAY'S REQUIREMENTS.

And again, it does not mean that Chet is always talking about today's requirement. The problem is that if you are the team lead and Chet said exactly what is quoted here, you make a mistake by blindly assuming Chet is trying to solve 3-week-away problem. It may be the case, it may be today's requirement that will become visible in 3 weeks.

> It’s Chet that refuses to accept that

Who cares about what Chet accepts or not. Neither me, you or the author has to agree with Chet. Just LISTEN to him to check if what he is talking about is in fact about the current solution failing TODAY'S REQUIREMENT (or if today's requirement were misleading) or not.

Again, for the hundredth time: if Chet is indeed talking about a future requirement, then say "no" to him. But in this scenario, with the exact quote that is used, you don't have enough information to understand if Chet is talking about today's requirement or future-in-3-weeks requirement.

> Chet himself has said that B will matter in 3 weeks. He hasn’t said that B matters now.

And I gave you several examples where people can say that the failure of doing the task according to the requirement of TODAY will only appear later.

That's your problem: you see "3 weeks" and you conclude "so it is not today's subject".

If today's subject is to install the correct wheels, if you install the incorrect wheels, which will break down in 3 weeks, you failed TODAY'S PROBLEM. Today's problem was to install the correct wheels, not the incorrect wheels.

Or, even more generally: if I write a piece of code and forget about some requirements, if someone said "hey, you forgot some of the requirements, when we are going to plug it with this other tool in 3 weeks, it will crash", I cannot say "if it does not work in 3 weeks, then it means it is a different feature". If what you say is true, then I can always write incorrect code that will not play nicely with the rest of the systems when deployed, and just say "we haven't deployed yet, so my code is perfectly fine".

In fact, another way of seeing this: almost all mistake in today's requirement can be magically transformed in any future requirement according to you: just postpone running the unit test: "I've finished the code and it looks ok when I look at it. Chet is saying that the unit test will crash in 3 weeks when we are going to run the unit test, so this mistake in the code is a future-hypothetical-different-feature"

> Do you agree or not with that statement?

I agree with that statement. What I don't agree with is saying that just because Chet says "3 weeks", it means it is not about the current problems.

That's the common problem with some people defending YAGNI. They are talking about "meditation on timing" and "building too soon or too late", but they don't realise that knowing if the problem is today's problem or the problem is 3-weeks-away problem is not as trivial as just noticing the word "3 weeks".