[cauch]

> It’s about something that has no value for today’s context superseding something that do.

But this is incorrect. Chet is saying "if we interpret today's requirement this way, what we do today has no value, if we interpret today's requirement this other way, what we do today has value". (and if he is in fact not saying that, the problem is that you and the author have no idea if he was saying that or not, you just saw "3 weeks" and concluded, incorrectly, that it is not about today's requirement)

Please check my other comment for an illustrative example.

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

That is factually not true. Take my illustrative example of my other comment: Day 1 requirement has ABSOLUTELY NOT VALUE if the devs that implement it don't listen to someone who said "in Day 5, we will be in this situation, so Day 1 requirement has only values if done this way and not that way".

> Let’s say you need to add logging for a web app to be able to quickly troubleshoot it. ...

Your example does not prove anything. We here all agree that over-engineering is a bad idea, and we can all come up with example where it is done.

What you need to do, is to demonstrate that ignoring what we already know for sure will happen in 3 weeks will never be less efficient than taking 5 minutes to pick the correct solution between two simple solutions, one compatible with in 3 weeks and one not.

This is how you demonstrate. If you say "f(x) is always positive", the demonstration is not to present some x values that are positive, the demonstration is to find a way to show that there is no x values for which f(x) is negative. If you restrict yourself to "let's assume that Chet solution to be compatible with the situation in 3 weeks is complex and will not be needed", of course you will conclude what you conclude. What you need to do is to convince us that it is impossible to have a situation where the information of what will be in 3 weeks will never be useful.

Because this is the point: in the situation in the article, the author has not enough information to know if Chet solution is complicated or not something needed. In fact, according to Chet, it is something needed, and the simple solution has therefore __zero value__.

[skydhash]

> Chet is saying "if we interpret today's requirement this way, what we do today has no value, if we interpret today's requirement this other way, what we do today has value".

He is certainly not saying that. The premise is that the simple thing has value for today, the complicated thing has value for today and in 3 weeks time.

> than taking 5 minutes to pick the correct solution between two simple solutions, one compatible with in 3 weeks and one not.

The choice is between a simple solution that will solve today’s issue and a complicated solution (which will take more time) that will also solve an hypothetical situation in 3 weeks.

> in the situation in the article, the author has not enough information to know if Chet solution is complicated or not something needed.

The premise of the article is that the solution is indeed complicated and not something needed today. You may have also been in similar situation. You don’t invalidate an argument by pointing that the premise isn’t true when there’s no argument made that it will always hold true.

Saying that P imply Q, does not mean P is always true.

[cauch]

Let me answer to your 2 comments here.

My criticism against YAGNI as a sane approach is not that things cannot be out-of-scope or over-engineered. My criticism against YAGNI is that it teaches developers to be unable to see a situation and think "yeah, maybe it's a bad over-engineering thing, or maybe it is not". It teaches devs to read __everything__ as bad over-engineering.

In your comment, you are showing exactly that. If you are not "contaminated" by YAGNI, you will look at the situation as described and not jump to the conclusion that "the premise is obviously that ...".

Here, you are saying "He is certainly not saying that". But if you look exactly what he is saying in the dialog, he MAY be saying that, but he also MAY NOT. This is my criticism: YAGNI trained you to misinterpret.

In your other comment, you say that Chet ask for developing something for "a powerful engine as the user may like to go offroad with a trailer". Where this even come from? Are you really unable to mentally conceive, in your head, a simple situation where Chet is talking about the exact motor that was planned from the start?

You are saying that Chet is talking about a motor for going offroad with a trailer, and yet, in the article, Chet says "but in 3 weeks that will be insufficient so since we’re going to need this" followed by "You don’t understand. We’re definitely going to need it. See, here’s an example…" followed by "But we really are…".

And at no point, absolutely no point, you thought "wait, maybe Chet is not being excited by a crazy hypothetical situation, maybe Chet is just talking about something ... we are really going to need it ... because it is in today's project goal, because it is just written that it is what we need to build and what the users are asking for".

You keep saying "the premise", but "the premise" is my criticism. I understand that the author is presenting the situation as if Chet is getting out of scope and uselessly complex. My criticism is that in the described situation, the author should recognised that this premise is just an assumption, and that he should ask for more information.

Maybe another example to illustrate. "Hello, my name is Bill, and I really think it's a bad idea to put wall paint in food. Let's take this situation, my friend Bob is coming to help me to cook, and he says "oh, I think it would be better if this birthday cake was more colorful". I immediatly said "Nope, No way", I knew he wanted to add wall paint in the cake. Bob said "maybe we can go to the shop and get ...". "No" I interrupted him. I would not go to the DYI shop to buy wall paint, it's ridiculous."

According to you, you are saying "well, it is the premise of the article that Bob want to use wall paint in the cake". But beyond the premise, this article still shows that Bill has a totally useless and strange reaction: normally, Bill should not have jumped to the conclusion that Bob want to put wall paint in the food.

Well, this conversation with you is a good illustration of why YAGNI is a terrible idea. In this whole conversation, you really struggled even conceive a situation where someone like Chet will use the same language but will not want to replace the project motor for another one to do offtrail with a trailer, but was simply talking about the motor that was planned all along in the project.

Unfortunately, because of YAGNI, there are more and more devs that are unable to see useful discussion without jumping on the conclusion that the whole discussion should be discarded.

[skydhash]

> You keep saying "the premise", but "the premise" is my criticism. I understand that the author is presenting the situation as if Chet is getting out of scope and uselessly complex. My criticism is that in the described situation, the author should recognised that this premise is just an assumption, and that he should ask for more information.

There’s a premise that you know can be true. There’s a logical reasoning that you don’t seem to be against. There’s also a conclusion that you also don’t disagree in your comments.

If the whole thread is you arguing about the premise and saying there may be a chance of it not being true, then this is not a discussion. It’s speculative fiction.

[cauch]

> If the whole thread is you arguing about the premise and saying there may be a chance of it not being true, then this is not a discussion. It’s speculative fiction.

But it is a really concrete question. Me or other people may be in Chet's situation, so it is important that you just not answer "if you are not over-engineering, then it's a different premise, so it does not count, you don't really exist".

We both agree that over-engineering is bad. I guess you agree that sometimes, someone may propose a different solution that is not over-engineering? My question, and it is not a trick question, is: can you explain me what this person should do in this situation.

It is not a trick question, it is real: my impression from this discussion is that if I'm in a situation where I have a constructive proposal, not out-of-scope, totally within the project goal, that will help the situation reaching its goal more smoothly, then whatever I say, you will just answer me "you ain't gonna need it", the same way the author did to Chet.

Let's imagine that Chet is speaking to the author of the article, and let's imagine that Chet does not want to plan for a new offroad motor pushing a trailer. Let's imagine that Chet is talking about the current project, its exact current goal, that within this project, they plan to use a standard Sedan 500 pounds engine, and that Chet is charged by the author of the article of installing wheels, but that the author has chosen a simplistic approach and that, as a consequence, these wheels will not be able to support a 500 pound engine. For example, the author of the article has asked Chet to do a "simple-on-axle-mounting" approach, and that car engineers have demonstrated that for more than 400 pounds engine, you need a more complex "double-corkscrew-mounting" (I made this up of course). Installing the wheels is the current task, and installing the engine will happen in 3 weeks. How can Chet approach the author of the article?

In the article, Chet approach the author by saying "I could do this simplistic thing now but in 3 weeks that will be insufficient so since we’re going to need this more complicated thing I want to do it now". What should have he said instead? Why this sentence is bad and what make this sentence sounds like Chet is talking about something out of scope? The author does not know that the "simple-on-axis-mounting" approach is discredited. What in this simple sentence informs the author of the article that Chet is not trying to inform them that this approach is not correct and that he is instead talking about out-of-scope over-engineering?

[skydhash]

Trying to answer your question.

Your example does not work with the article because the simplistic approach is already proven to be an ok design. The wheel will support the engine. The complex approach (maybe a non standard suspension) is for an hypothetical scenario that Chet believes will occur in 3 weeks. That scenario is not the mounting of the engine which is already planned and scoped.

You don't delay a project because of an hypothetical scenario. What you do is evaluate and present the risks and a possible solutions. You don't rush in the implementation unilaterally. That's a cowboy mindset.

> What in this simple sentence informs the author of the article that Chet is not trying to inform them that this approach is not correct and that he is instead talking about out-of-scope over-engineering?

  I could do this simplistic thing now

That means the solution is OK and the implementation will provide some value for the customer.

  but in 3 weeks that will be insufficient

How does he know that? Where's the argument, not merely examples as in the rest of the dialogue, but real objective facts and numbers (like there's another requirement that the customers are pressing us). It's very likely that any such situation would have skipped past by when designing the simple approach.

  so since we’re going to need this more complicated thing 

Will we really need it? We know that we don't need it today. What will change in a few week that will make it a requirement? Again what needed here is objective facts. Not what-if scenarios.

  I want to do it now

Why the rush? Why can't it wait for 2 weeks when we can tie the feature to the name of few customers (assuming it's B2B) or market analysis. Why do we need to spend let's say a week on this complicated approach when we can solve the problem in a day or two and ship it.

That's all the questions I would have asked if I was not familiar with the project. But if you're the project lead, the only thing that would have led you to question yourself is if Chet has said the simplistic approach does not work. But it does.

[cauch]

> Your example does not work with the article because the simplistic approach is already proven to be an ok design.

Where is it done? No where in the article the author said "Chet said it will not work in 3 week, so I demonstrated that it will work in 3 weeks". The author just __assume__ it is an ok design.

What I'm telling you is that you and the author are acting in a way that shut down the conversation in case you are right AND in case you wrong.

Your answer to that is "I'm mentally impossible to conceive a scenario where the author missed something, did not realise the 'simple-one-axle-mounting' approach will fail". That is such a red flag.

> The complex approach (maybe a non standard suspension) is for an hypothetical scenario that Chet believes will occur in 3 weeks.

This is not what I ask you. I ask you to say what Chet should say in the situation where Chet is right, where the author design is incorrect and Chet scenario is not hypothetical. You keep twisting back "no but let's just pretend it cannot happen". This is my worry: are you even able to conceive that it can happen?

> That means the solution is OK and the implementation will provide some value for the customer.

What? That is definitively not how normal people would understand this sentence. Are you a native english speaker? According to you "I could do this simplistic thing now but it would not work" is an impossible sentence? Or that this sentence is saying that the solution is OK because the sentence contains "I could do this thing"?

> How does he know that?

Well, that's the point. In this step of this dialog, you don't know yet, and yet you already concluded that Chet does not know and that you know.

> Where's the argument, not merely examples as in the rest of the dialogue, but real objective facts and numbers

Chet is introducing the problem, he is shut down before he can even give his first example. Chet may have plenty of objective facts and numbers, but the author shut down the conversation before it even happen. In this dialog, Chet is __trying__ to bring facts and numbers, starting by a concrete illustration, but he is interrupted before he can do it.

You are so full of it. You are saying "Chet did not arrive and slap the author with a book full of facts, so it is the proof that Chet has no idea of what he is talking about and should be shut down before he can prove this assumption is wrong".

> Will we really need it?

You don't know if you really need it or not, you don't know if Chet has facts and numbers. Because YAGNI is shit, you just assumed that the situation is over-engineer, while you have no idea of what the situation is and stop people who try to explain it to you.

> We know that we don't need it today.

No you don't. You just stop Chet explaining and interrupt him.

> What will change in a few week that will make it a requirement? Again what needed here is objective facts. Not what-if scenarios.

This is what I saying from the start: when Chet reacts like that, the fact that the author does not say "wait a minute, do you have objective facts" is a red flag. The fact that the author goes to the what-if scenario that his design will obviously work, without providing any objective facts, is the problem.

> Why the rush?

Where is there any rush. The situation is extremely simple. The guy say: "hear me you, I think I will be wasting me time doing this". The author answers "shut up" and __assume__ that Chet has no argument.

> That's all the questions I would have asked if I was not familiar with the project. But if you're the project lead, the only thing that would have led you to question yourself is if Chet has said the simplistic approach does not work. But it does.

I saw very experienced devs failing at that all the time. In this article, the author is assuming he has a good understanding of the project and shut down anyone who can bring important information.

Your approach: "I'm the lead, so I cannot be wrong, so I assume Chet is incorrect when he said the simplistic approach will not work" is so bad. Do you even realise that?

You are a perfect example of what I was talking about. What would you have lost in just hearing Chet out? But now, YAGNI is just shit, it pushes people to have this attitude to assume that only them know the truth.