5 ms·

You are constantly ignoring the main point: There’s a simple solution for today’s requirement, and there’s a complicated solution that will also solve a future,

You are constantly ignoring the main point: There’s a simple solution for today’s requirement, and there’s a complicated solution that will also solve a future, not existing yet, requirement. Chet want to write the later, not the former. The complicated solution is trying to solve two problems at once, and one of them does not exist yet. It’s speculative. > The fact that the author just chooses to not even try to check if Chet is correct or not should be a red flag. Chet himself says that the thing will be necessary 3 weeks from now, implying that it’s not necessary today. You can anticipate changes and plan for it. You can brainstorm it. You can even question the current requirements. What you don’t do is solving something that does not exist. When we say YAGNI, that means the problem you’re stating, even when reasonable by itself, does not apply to the current context. It’s easier to revise a simple design later when needed, than refactoring a complex one that have a flawed assumption.

Scubabear68 4mo ago
I think you're missing the point of the poster you are replying to. You make it sound like 3 weeks is 3 years. It ain't. Very little, or possible nothing at all, is going to change in 3 weeks. If you are that myopic - as the XP people were - then constant failure is not going to be surprising. It will be expected.
- skydhash 4mo ago
  It’s not about the specific timeframe. It’s about something that has no value for today’s context superseding something that do. It’s ok to anticipate changes, it’s not ok to act as if they’re already here when it’s clear that they’re not. And the other axis is the lean towards complexity. Let’s say you need to add logging for a web app to be able to quickly troubleshoot it. The design was to create a simple module that printf to stderr. But then the dev comes to you with a new complicated design involving elastic search and what not, saying that we will need it in 3 weeks to dissect the logs, etc. It may have been a good idea, but it’s not valuable. The correct idea is to put that on the backlog, not to start writing code for it. Implementing complicated idea takes more time than implementing simple idea, while the value is the same. When there’s a need for having something elastic search for the logs, it will be easy to refactor the simple code that we have than fixing the possibly flawed implementation that would have resulted if we went with the complex design.
  - cauch 4mo ago
    > 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 4mo ago
      > 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 4mo ago
> There’s a simple solution for today’s requirement, and there’s a complicated solution that will also solve a future, not existing yet, requirement. There are tons of examples that show that your reasoning is incorrect. Let's invent one: you need to build a car. Day 1: put the front left wheel on the frame structure. Day 2: put the front right wheel on the frame structure, Day 3: put the back left wheel on the frame structure, Day 4: put the back right wheel on the frame structure, Day 5: attach that particular motor on the frame. Now, you are on Day 1, and Chet arrive and say "this wheel will not do, it will never support the motor that we need to install on day 5". You are telling me that what Chet said is to be ignored because "it is a requirement for day 5". But it is not. What Chet has done is not bringing a requirement of day 5 into day 1, what Chet has done is that it has noticed an incorrect interpretation in Day 1 requirement. The requirement for Day 1 should have been read as "put the front left wheel on the frame structure, but of course, it goes without saying, use a wheel that is compatible with the car we want to build". You saying that because Chet is using Day 5 information, the point he is making is not about Day 1 requirement is incorrect. The thing is: Day 1 requirement and Day 5 requirement don't live on their own. Hell, your job is not to "just do Day 1 requirement" and it has never been. No one, absolutely no one, want a frame structure with just one wheel and no motor. In the article, Chet does that: he tries to send the message "this is the point of the work, we will need it, it is what we plan to build, so you need to take that into account in today's requirement interpretation. If you don't account for it, you better not even do today's requirement". And, and let me be clear on that, maybe the element that Chet brings will end up being not relevant or not needed. But the problem is that neither you or the author know that yet, and you reject the discussion before you can even discover if it's the case or not. The problem is that author and you just saw "Day 5" or "in 3 weeks" and, because YAGNI is a terrible advance, jumped on the conclusion "it is in the future, so it has nothing today with today's requirements". (oh, and in practice, the people who says "YAGNI" will then say "well, the problem is Day 1 requirement, each requirement should go into excruciating details to re-explain the whole point of the work, should think of all the possible interpretation and should be written by someone who know better than me how to build the implementation to each line of code, but somehow should waste their time explaining the project to someone less competent". Again, the problem with this argument is that the solution of "use your brain, build things carefully" creates a way easier and elegant solution than YAGNI+ridiculously unrealistic requirements.)

Scubabear68 4mo ago

I think you're missing the point of the poster you are replying to. You make it sound like 3 weeks is 3 years. It ain't. Very little, or possible nothing at all, is going to change in 3 weeks. If you are that myopic - as the XP people were - then constant failure is not going to be surprising. It will be expected.

skydhash 4mo ago
It’s not about the specific timeframe. It’s about something that has no value for today’s context superseding something that do. It’s ok to anticipate changes, it’s not ok to act as if they’re already here when it’s clear that they’re not. And the other axis is the lean towards complexity. Let’s say you need to add logging for a web app to be able to quickly troubleshoot it. The design was to create a simple module that printf to stderr. But then the dev comes to you with a new complicated design involving elastic search and what not, saying that we will need it in 3 weeks to dissect the logs, etc. It may have been a good idea, but it’s not valuable. The correct idea is to put that on the backlog, not to start writing code for it. Implementing complicated idea takes more time than implementing simple idea, while the value is the same. When there’s a need for having something elastic search for the logs, it will be easy to refactor the simple code that we have than fixing the possibly flawed implementation that would have resulted if we went with the complex design.
- cauch 4mo ago
  > 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 4mo ago
    > 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 4mo ago

> There’s a simple solution for today’s requirement, and there’s a complicated solution that will also solve a future, not existing yet, requirement. There are tons of examples that show that your reasoning is incorrect. Let's invent one: you need to build a car. Day 1: put the front left wheel on the frame structure. Day 2: put the front right wheel on the frame structure, Day 3: put the back left wheel on the frame structure, Day 4: put the back right wheel on the frame structure, Day 5: attach that particular motor on the frame. Now, you are on Day 1, and Chet arrive and say "this wheel will not do, it will never support the motor that we need to install on day 5". You are telling me that what Chet said is to be ignored because "it is a requirement for day 5". But it is not. What Chet has done is not bringing a requirement of day 5 into day 1, what Chet has done is that it has noticed an incorrect interpretation in Day 1 requirement. The requirement for Day 1 should have been read as "put the front left wheel on the frame structure, but of course, it goes without saying, use a wheel that is compatible with the car we want to build". You saying that because Chet is using Day 5 information, the point he is making is not about Day 1 requirement is incorrect. The thing is: Day 1 requirement and Day 5 requirement don't live on their own. Hell, your job is not to "just do Day 1 requirement" and it has never been. No one, absolutely no one, want a frame structure with just one wheel and no motor. In the article, Chet does that: he tries to send the message "this is the point of the work, we will need it, it is what we plan to build, so you need to take that into account in today's requirement interpretation. If you don't account for it, you better not even do today's requirement". And, and let me be clear on that, maybe the element that Chet brings will end up being not relevant or not needed. But the problem is that neither you or the author know that yet, and you reject the discussion before you can even discover if it's the case or not. The problem is that author and you just saw "Day 5" or "in 3 weeks" and, because YAGNI is a terrible advance, jumped on the conclusion "it is in the future, so it has nothing today with today's requirements". (oh, and in practice, the people who says "YAGNI" will then say "well, the problem is Day 1 requirement, each requirement should go into excruciating details to re-explain the whole point of the work, should think of all the possible interpretation and should be written by someone who know better than me how to build the implementation to each line of code, but somehow should waste their time explaining the project to someone less competent". Again, the problem with this argument is that the solution of "use your brain, build things carefully" creates a way easier and elegant solution than YAGNI+ridiculously unrealistic requirements.)