7 ms·

It's predicting that you will predict wrong frequently enough to make it not worthwhile predicting at all. I apply the same logic at slots: the way to win is n

It's predicting that you will predict wrong frequently enough to make it not worthwhile predicting at all. I apply the same logic at slots: the way to win is not to play. >Creating abstraction for a code that was designed without being compatible with these abstraction has a huge cost I have never found it more expensive to create an abstraction after following the rule of 3. Indeed, ive always noticed that abstractions which are front loaded are nearly ALWAYS worse than abstractions built with hindsight. >As I've said, nothing is all white or all black. The problem with YAGNI is the developers think it's all white We think you're playing slots and remembering only the wins, believing that you're just naturally talented at predicting the future. Ive seen this attitude in hundreds of devs. They all think theyre uniquely able to anticipate the code base's future needs.

cauch 3mo ago
> I have never found it more expensive to create an abstraction after following the rule of 3. 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. Don't get me wrong, as I've said, I think that sometimes not over-building is a good idea. The problem is that YAGNI is the wrong solution. To avoid over-building, the solution is not to invent a rule that says "just don't build". The solution is to stop having developers thinking they know what is useful or what is not. > Indeed, ive always noticed that abstractions which are front loaded are nearly ALWAYS worse than abstractions built with hindsight. Again, you cannot know if it is worse or not. You are not the user. It may be good in some cases, it may be bad in other, and I have seen devs saying exactly what you said when their "abstractions in hindsight" was catastrophic. There is a lot of example, but just one: we built a system that was collecting data, the goal being to accumulate data for months and then analyse it. Few people involved in the project proposed some structure for the data, but the devs used YAGNI to do what they preferred (there was some objection but at the end, the devs just did what they wanted to do, ignoring the rest of the team because they were confident that they knew more than them how to build software). Later, we started the analysis, and realised all the data were crap: the devs kept changing the data structure by building their abstraction with hindsight, without even documenting when these modifications were deployed to the different sensors. We had a mix of data built based on different parameters with no way to know which part was using which parameters. After the project failure, I saw many devs still saying that they were right to use YAGNI, and being totally oblivious that it's their choice that doomed the project. They were, seriously, saying that it was a lack of requirement, or that the "users changed their mind", while it was not true at all (I was there, and I was not in either side, I just observed), the situation was well known from the start. The problem was they insisted to apply YAGNI as if they understood better than the other collaborators what as needed. > We think you're playing slots and remembering only the wins, believing that you're just naturally talented at predicting the future. You literally just said "ive always noticed that abstractions which are front loaded are nearly ALWAYS worse than abstractions built with hindsight". This is literally you remembering the amount of "win" and the amount of "loose". > Ive seen this attitude in hundreds of devs. They all think theyre uniquely able to anticipate the code base's future needs. That's exactly my point (and I'm not a dev). When you are saying "abstraction is better built in hindsight", you are just thinking you are smarter than other people. When the situation is that it is difficult to understand what we will need, the solution is to discuss together to understand what we will need. We may get it wrong sometimes, but we will get it right sometimes. If someone just decides to ignore other collaborators opinion and decides "we will need this abstraction", this person has way more chance to be wrong. If someone just decides to ignore other collaborators opinion and decides "we will not need this abstraction", this person has way more chance to be wrong too. YAGNI is just someone noticing that building a big house without following the plan led to extra work because they have to demolish the bits they've built on next door property, so they decide to build a small house without following the plan.
- MoreQARespect 3mo ago
  >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.

cauch 3mo ago

> I have never found it more expensive to create an abstraction after following the rule of 3. 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. Don't get me wrong, as I've said, I think that sometimes not over-building is a good idea. The problem is that YAGNI is the wrong solution. To avoid over-building, the solution is not to invent a rule that says "just don't build". The solution is to stop having developers thinking they know what is useful or what is not. > Indeed, ive always noticed that abstractions which are front loaded are nearly ALWAYS worse than abstractions built with hindsight. Again, you cannot know if it is worse or not. You are not the user. It may be good in some cases, it may be bad in other, and I have seen devs saying exactly what you said when their "abstractions in hindsight" was catastrophic. There is a lot of example, but just one: we built a system that was collecting data, the goal being to accumulate data for months and then analyse it. Few people involved in the project proposed some structure for the data, but the devs used YAGNI to do what they preferred (there was some objection but at the end, the devs just did what they wanted to do, ignoring the rest of the team because they were confident that they knew more than them how to build software). Later, we started the analysis, and realised all the data were crap: the devs kept changing the data structure by building their abstraction with hindsight, without even documenting when these modifications were deployed to the different sensors. We had a mix of data built based on different parameters with no way to know which part was using which parameters. After the project failure, I saw many devs still saying that they were right to use YAGNI, and being totally oblivious that it's their choice that doomed the project. They were, seriously, saying that it was a lack of requirement, or that the "users changed their mind", while it was not true at all (I was there, and I was not in either side, I just observed), the situation was well known from the start. The problem was they insisted to apply YAGNI as if they understood better than the other collaborators what as needed. > We think you're playing slots and remembering only the wins, believing that you're just naturally talented at predicting the future. You literally just said "ive always noticed that abstractions which are front loaded are nearly ALWAYS worse than abstractions built with hindsight". This is literally you remembering the amount of "win" and the amount of "loose". > Ive seen this attitude in hundreds of devs. They all think theyre uniquely able to anticipate the code base's future needs. That's exactly my point (and I'm not a dev). When you are saying "abstraction is better built in hindsight", you are just thinking you are smarter than other people. When the situation is that it is difficult to understand what we will need, the solution is to discuss together to understand what we will need. We may get it wrong sometimes, but we will get it right sometimes. If someone just decides to ignore other collaborators opinion and decides "we will need this abstraction", this person has way more chance to be wrong. If someone just decides to ignore other collaborators opinion and decides "we will not need this abstraction", this person has way more chance to be wrong too. YAGNI is just someone noticing that building a big house without following the plan led to extra work because they have to demolish the bits they've built on next door property, so they decide to build a small house without following the plan.

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