3 ms·

The article refers to "the much-abused YAGNI" and links to another blog post that goes into detail. Apparently some people take YAGNI to mean never anticipate a

The article refers to "the much-abused YAGNI" and links to another blog post that goes into detail. Apparently some people take YAGNI to mean never anticipate anything. Is that your experience? I've always taken it as a tie-breaker when you're unsure whether to anticipate or not, and I've had the impression that others take it the same way. Overall I like this article and the YAGNI one it links to.

ninkendo 7y ago
I take YAGNI to mean not developing abstractions until you have enough use cases to back them up. If you don't have a reason now to make an abstraction, don't do it yet. Wait until you have at least 3 use cases where you're repeating yourself before you come up with an abstraction that collapses them. You'll know better what the right abstraction will be once you have those use cases... any abstraction you come up with now is much more likely to be wrong. And a wrong abstraction is much worse than repeating yourself. Of course, if this is the umpteenth time you've done the same CRUD app that wraps a relational database, go ahead and use the abstractions you know worked before, because in that case, you've already seen the use cases before and you have a better idea of what abstractions will work.
- Kivutar 7y ago
  Exactly.
- brlewis 7y ago
  https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...
rubinelli 7y ago
It is easy to look back and say, "I should have made this modular," or "I should have isolated that external dependency." It is easier to see how another level of indirection would have saved you work after the fact, but maybe YAGNI was the right call at the time. That's the trap that Magic and poker players call results-oriented thinking: You got burned once by making the best decision available given the information you had, and you give that experience a disproportionate weight, like the player that lost big with a pair of kings in his hand, and undervalues a pair of kings after that.
- sullyj3 7y ago
  When you look back, you're looking back from the particular world where X became a requirement. If instead, Y had become a requirement, you would be looking back wishing you had structured your code in some completely different way. YAGNI then applies to the extent that you can't predict which of X and Y it will be in advance.
hashmal 7y ago
Yes, I worked in teams where "YAGNI" would come up all the time, preventing any kind of actual code design/architecture. Every time YAGNI is mentioned, it should be put against code quality (maintainability, readability, testability, etc) because they are often opposite/fighting concepts: code quality, in the end, is all about making (not yet known) changes easily, which means you have to anticipate different possible futures. The sweet spot between these two principles is not easy to find. Thinking and discussing about this on projects is a good start.
- astrobe_ 7y ago
  > is all about making not yet known changes easily, which means you have to anticipate different possible futures. The absurdity of this statement should immediately convince you that YAGNI is fundamentally correct. Anticipating the future is literally science-fiction. More often, it is superstition ; developers are very prone to FUDing themselves. The thing is, demands create products and products create new demands. Even on small personal hobby projects this feedback loop can happen and sometimes lead to a full rewrite. More over, code quality is far from being "all about making changes easily" [1] > The sweet spot between these two principles is not easy to find. Thinking and discussing about this on projects is a good start. There's nothing to discuss about it at the coding/design level. Anticipating a demand, generalizing it is done at a level above, or by someone else who has a better understanding of the market or the customer. Know your place. What you have is a document that tells you what needs to be done and a lot of freedom as for how to implement it. The only case where anticipation can play a role is when you have several equal implementation options. There you can choose the one that seems more resilient to imaginary changes in the demands. [1] https://en.wikipedia.org/wiki/ISO/IEC_9126 https://en.wikipedia.org/wiki/ISO/IEC_9126

ninkendo 7y ago

I take YAGNI to mean not developing abstractions until you have enough use cases to back them up. If you don't have a reason now to make an abstraction, don't do it yet. Wait until you have at least 3 use cases where you're repeating yourself before you come up with an abstraction that collapses them. You'll know better what the right abstraction will be once you have those use cases... any abstraction you come up with now is much more likely to be wrong. And a wrong abstraction is much worse than repeating yourself. Of course, if this is the umpteenth time you've done the same CRUD app that wraps a relational database, go ahead and use the abstractions you know worked before, because in that case, you've already seen the use cases before and you have a better idea of what abstractions will work.

Kivutar 7y ago
Exactly.
brlewis 7y ago
https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...

rubinelli 7y ago

It is easy to look back and say, "I should have made this modular," or "I should have isolated that external dependency." It is easier to see how another level of indirection would have saved you work after the fact, but maybe YAGNI was the right call at the time. That's the trap that Magic and poker players call results-oriented thinking: You got burned once by making the best decision available given the information you had, and you give that experience a disproportionate weight, like the player that lost big with a pair of kings in his hand, and undervalues a pair of kings after that.

sullyj3 7y ago
When you look back, you're looking back from the particular world where X became a requirement. If instead, Y had become a requirement, you would be looking back wishing you had structured your code in some completely different way. YAGNI then applies to the extent that you can't predict which of X and Y it will be in advance.

hashmal 7y ago

Yes, I worked in teams where "YAGNI" would come up all the time, preventing any kind of actual code design/architecture. Every time YAGNI is mentioned, it should be put against code quality (maintainability, readability, testability, etc) because they are often opposite/fighting concepts: code quality, in the end, is all about making (not yet known) changes easily, which means you have to anticipate different possible futures. The sweet spot between these two principles is not easy to find. Thinking and discussing about this on projects is a good start.

astrobe_ 7y ago
> is all about making not yet known changes easily, which means you have to anticipate different possible futures. The absurdity of this statement should immediately convince you that YAGNI is fundamentally correct. Anticipating the future is literally science-fiction. More often, it is superstition ; developers are very prone to FUDing themselves. The thing is, demands create products and products create new demands. Even on small personal hobby projects this feedback loop can happen and sometimes lead to a full rewrite. More over, code quality is far from being "all about making changes easily" [1] > The sweet spot between these two principles is not easy to find. Thinking and discussing about this on projects is a good start. There's nothing to discuss about it at the coding/design level. Anticipating a demand, generalizing it is done at a level above, or by someone else who has a better understanding of the market or the customer. Know your place. What you have is a document that tells you what needs to be done and a lot of freedom as for how to implement it. The only case where anticipation can play a role is when you have several equal implementation options. There you can choose the one that seems more resilient to imaginary changes in the demands. [1] https://en.wikipedia.org/wiki/ISO/IEC_9126 https://en.wikipedia.org/wiki/ISO/IEC_9126