3 ms·

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 shou

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

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