7 ms·

>This is the problem: your judgement is biased. You think it was a good idea, but in reality, you have no real idea if it was or not. My judgement is based upo

>This is the problem: your judgement is biased. You think it was a good idea, but in reality, you have no real idea if it was or not. My judgement is based upon my experience trying it both ways many times over the course of decades. >To avoid over-building, the solution is not to invent a rule that says "just don't build". It isnt a rule that says dont build what you need now. It is a rule that says dont try to anticipate what architectures or abstractions might be needed in the future. >Again, you cannot know if it is worse or not. I used to think like you when I was more junior (most do), so it's not like I dont have a lot of practice thinking that YAGNI applied only sometimes. It was hard experience that taught me that it was pretty universal.

cauch 3mo ago
> My judgement is based upon my experience trying it both ways many times over the course of decades. You miss my point: if you are the person who develop the code, your judgement is biased, because you are not the user. You will judge the success without knowing if you delivered what the user needed or not. I saw it again and again, especially with devs who have a lot of experience, because they don't realise that the blind spot is independent to experience and get a false sense of confidence. > It isnt a rule that says dont build what you need now. It is a rule that says dont try to anticipate what architectures or abstractions might be needed in the future. And what mine and the comment I answered are saying is that unfortunately YAGNI is badly designed in a way that leads devs to think there is only two options: 1. anticipate what architectures or abstractions might be needed in the future, 2. not anticipate anything. The correct solution is not to anticipate what __might__ be needed, it is to listen to people who have a better idea of what __is__ needed. Again (but are you even reading what I said, you totally ignored some of the points in my previous comment), we all agree here that over-building or jumping to architecture or abstraction that will not be needed is a bad thing. But YAGNI as a solution to this problem is stupid. The solution is to be careful with the assumption and cross-check with the team (which include non-dev). YAGNI recommends to treat one ASSUMPTION ("it will not be needed") as default, which is as stupid as assuming the opposite. And the reason devs think it works is that over-development has externalities that affect devs (a bloated software is harder to manage) while under-development has externalities that affect non-devs (users have to live with the absence of features, delivering something that does half the job is accepted by the users because it is better than nothing and because they don't know if the missing features is just "irreducible complexity" that devs cannot fix). > I used to think like you when I was more junior (most do), so it's not like I dont have a lot of practice thinking that YAGNI applied only sometimes. 100% of the devs who created bad software applying YAGNI stupidly said exactly that. These bad software were created because these devs thought they had plenty of experience and that they knew better. (and by the way, I'm not junior, and I have delivered a lot of code that ended up in production, mainly when I had to step up when devs were not able to do so, sometimes because they were saying "YAGNI") > It was hard experience that taught me that it was pretty universal. Exactly what the devs who messed up the projects I have as examples have said.
- skydhash 3mo ago
  YAGNI is mostly an answer to someone that says "let's create this abstraction", but can't argue why it's really needed. If you can't argue about why you need an abstraction, the best strategy is to not create it. Because removing it afterwards may be more costly than implementing it (if it ever get done). It's not an objective answer that "you really not gonna need that". It's more "No clear explanation about that abstraction? You ain't gonna need it".
  - cauch 3mo ago
    Look at the article itself: > Chet said, “You don’t understand. We’re definitely going to need it. See, here’s an example…” > Me (interrupting), “You aren’t going to need it.” > Chet, get frustrated, “But we really are…” > Me, “You aren’t going to need it.” This is a clear example of YAGNI being used when the dev, actively, does not care if the other person has any argument to defend it will be needed. YAGNI itself is badly designed, it gives the wrong answer. It should be "Build Thing Carefully": no abstraction if no argument, abstraction if no good argument beyond "YAaGnNIii". And I know devs would just say "but devs who don't listen is super rare", but it is not true: you probably read the article and did not flinch, not noticing that it's a clear situation where the dev actively refuse to listen to the arguments. How many time did you witness or participate to such situation and still think it never happens? At the end, I don't understand: just do "Build Thing Carefully", where what you built is well-thought, and not only you get YAGNI for free, but you also avoid the problem with refusing to build something that is needed.
    - skydhash 3mo ago
      > This is a clear example of YAGNI being used when the dev, actively, does not care if the other person has any argument to defend it will be needed The first paragraph set the context I could do this simplistic thing now but in 3 weeks that will be insufficient so since we’re going to need this more complicated thing I want to do it now. You can solve today’s problem and do some groundwork to extend later. What you don’t do is solving today’s problem with a solution for a future problem. Whatever complicated thing that may be wanted, meaning you don’t have the full specification, as it’s not a current problem for a stakeholder. In systems design, you’re solving problems belonging to the stakeholder, the project resources, and engineering needs and constraints. Going outside the union of those sets is overengineer, building things no one needs, costing resources that should be allocated to other things, and complicating the design because other things need to react to that new feature. > YAGNI itself is badly designed, it gives the wrong answer. It should be "Build Thing Carefully": no abstraction if no argument, abstraction if no good argument beyond "YAaGnNIii". YAGNI is not a case again against abstraction. It’s a case against features. You can always design code to modularize and decouple an implementation from where it’s used. What you don’t do is creating extra code for things that are not needed yet. Why? Because anything that is going to be needed between now and that X moment in the future will have to take your design into account. The cost may be negligible, but often it’s not. IMO, there’s no argument that can stand against “This is not part of the current requirements”. Solving future requirements ahead of time is a fool’s errand. But you can always make the current design flexible enough for future changes.

cauch 3mo ago

> My judgement is based upon my experience trying it both ways many times over the course of decades. You miss my point: if you are the person who develop the code, your judgement is biased, because you are not the user. You will judge the success without knowing if you delivered what the user needed or not. I saw it again and again, especially with devs who have a lot of experience, because they don't realise that the blind spot is independent to experience and get a false sense of confidence. > It isnt a rule that says dont build what you need now. It is a rule that says dont try to anticipate what architectures or abstractions might be needed in the future. And what mine and the comment I answered are saying is that unfortunately YAGNI is badly designed in a way that leads devs to think there is only two options: 1. anticipate what architectures or abstractions might be needed in the future, 2. not anticipate anything. The correct solution is not to anticipate what __might__ be needed, it is to listen to people who have a better idea of what __is__ needed. Again (but are you even reading what I said, you totally ignored some of the points in my previous comment), we all agree here that over-building or jumping to architecture or abstraction that will not be needed is a bad thing. But YAGNI as a solution to this problem is stupid. The solution is to be careful with the assumption and cross-check with the team (which include non-dev). YAGNI recommends to treat one ASSUMPTION ("it will not be needed") as default, which is as stupid as assuming the opposite. And the reason devs think it works is that over-development has externalities that affect devs (a bloated software is harder to manage) while under-development has externalities that affect non-devs (users have to live with the absence of features, delivering something that does half the job is accepted by the users because it is better than nothing and because they don't know if the missing features is just "irreducible complexity" that devs cannot fix). > I used to think like you when I was more junior (most do), so it's not like I dont have a lot of practice thinking that YAGNI applied only sometimes. 100% of the devs who created bad software applying YAGNI stupidly said exactly that. These bad software were created because these devs thought they had plenty of experience and that they knew better. (and by the way, I'm not junior, and I have delivered a lot of code that ended up in production, mainly when I had to step up when devs were not able to do so, sometimes because they were saying "YAGNI") > It was hard experience that taught me that it was pretty universal. Exactly what the devs who messed up the projects I have as examples have said.

skydhash 3mo ago
YAGNI is mostly an answer to someone that says "let's create this abstraction", but can't argue why it's really needed. If you can't argue about why you need an abstraction, the best strategy is to not create it. Because removing it afterwards may be more costly than implementing it (if it ever get done). It's not an objective answer that "you really not gonna need that". It's more "No clear explanation about that abstraction? You ain't gonna need it".
- cauch 3mo ago
  Look at the article itself: > Chet said, “You don’t understand. We’re definitely going to need it. See, here’s an example…” > Me (interrupting), “You aren’t going to need it.” > Chet, get frustrated, “But we really are…” > Me, “You aren’t going to need it.” This is a clear example of YAGNI being used when the dev, actively, does not care if the other person has any argument to defend it will be needed. YAGNI itself is badly designed, it gives the wrong answer. It should be "Build Thing Carefully": no abstraction if no argument, abstraction if no good argument beyond "YAaGnNIii". And I know devs would just say "but devs who don't listen is super rare", but it is not true: you probably read the article and did not flinch, not noticing that it's a clear situation where the dev actively refuse to listen to the arguments. How many time did you witness or participate to such situation and still think it never happens? At the end, I don't understand: just do "Build Thing Carefully", where what you built is well-thought, and not only you get YAGNI for free, but you also avoid the problem with refusing to build something that is needed.
  - skydhash 3mo ago
    > This is a clear example of YAGNI being used when the dev, actively, does not care if the other person has any argument to defend it will be needed The first paragraph set the context I could do this simplistic thing now but in 3 weeks that will be insufficient so since we’re going to need this more complicated thing I want to do it now. You can solve today’s problem and do some groundwork to extend later. What you don’t do is solving today’s problem with a solution for a future problem. Whatever complicated thing that may be wanted, meaning you don’t have the full specification, as it’s not a current problem for a stakeholder. In systems design, you’re solving problems belonging to the stakeholder, the project resources, and engineering needs and constraints. Going outside the union of those sets is overengineer, building things no one needs, costing resources that should be allocated to other things, and complicating the design because other things need to react to that new feature. > YAGNI itself is badly designed, it gives the wrong answer. It should be "Build Thing Carefully": no abstraction if no argument, abstraction if no good argument beyond "YAaGnNIii". YAGNI is not a case again against abstraction. It’s a case against features. You can always design code to modularize and decouple an implementation from where it’s used. What you don’t do is creating extra code for things that are not needed yet. Why? Because anything that is going to be needed between now and that X moment in the future will have to take your design into account. The cost may be negligible, but often it’s not. IMO, there’s no argument that can stand against “This is not part of the current requirements”. Solving future requirements ahead of time is a fool’s errand. But you can always make the current design flexible enough for future changes.