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