3 ms·
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 contra
by 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.
- skydhash 3mo agoYour argument is always about: We need to to task X today, we're going to do Task Y later. But we need both task X and task Y to complete the whole project. But the solution for task X is wrong because it conflicts with task Y. And when we get to task Y, we won't be able to deliver. And Chet know this. But the author don't want to listen to Chet, and the author is wrong for that. While the situation is: The project is already defined. There's task X to be done, and we have settle on a solution A for it. Chet is the one who will be implementing it. Chet uncovers a situation that leads him to believe that the solution B is better because of a constraint that will come in effect in 3 weeks. He says that he can implement A, but because we're going to need B in 3 weeks, let's scrap A and go with B instead. Now the author knows both A and B (and maybe B was discussed beforehand but Chet don't knows about it),and says that B don't matter, A is good enough. Instead of asking why, Chet decide to argue for the validity of B. The author reiterates that B doesn't matter. At the end Chet decides to walk away. And never wanted to learn why A is the better choice when B seems to be perfect. I was Chet at one time and never have someone like the author to rein me in. I get cured from wanting to implement complicated solution when client asked me for demos and I couldn't show anything because I was trying to solve everything. And you're right, they don't care about code. They care about working product, and today, not in 3 weeks. So between A and B, I deliver A first, then worry about B. 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, you don't immediately try to prove your position. Imagine doing that in the army.
- cauch 3mo ago> 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.