4 ms·

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

by cauch 3mo ago

> 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 3mo ago
> 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 3mo ago
  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.

by cauch 3mo ago

skydhash 3mo ago

> 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 3mo ago
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.