alt Hacker News> 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
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.
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.