4 ms·

Developers aren't great at sharing nomenclature, but by what seems to be the most common definition, YAGNI refers to not going off and implementing something th

Developers aren't great at sharing nomenclature, but by what seems to be the most common definition, YAGNI refers to not going off and implementing something that is more fun to implement, but isn't needed right away (if ever). Focus on what you actually need to get your project to a desirable state. It doesn't say you should not consider future considerations in your design. In fact, it suggests that you should design your software to be as accommodating as possible, most notably by ensuring testing is core to your design to assist you when the time for change comes. The other poster you refer to and YAGNI seem to be in alignment.

PH95VuimJjqBqy 3y ago
YAGNI is more about design than implementation. It's about worrying about future concerns rather than what you know you need right now. The truth is in the middle, sometimes you need to design for the future and sometimes you don't. Often designing for the future just means making sure you haven't designed yourself into a corner rather than being able to fully deal with the future but that's a nuance most people miss.
- randomdata 3y ago
  > YAGNI is more about design than implementation Not as it seems to be usually defined, but I agree that programmers are bad for not sharing a common nomenclature. We can't even agree what something as simple as enums are. So, no doubt that there are camps who hold that perspective. enterprise_cog clearly comes from the "don't implement", not "don't design" definition, though.
  - PH95VuimJjqBqy 3y ago
    "you aint gonna need it" can be clarified as "you aint gonna need all those extension points". it can also mean you don't need functionality you're not using, including implementations for those extension points.
    - randomdata 3y ago
      While I accept your definition, because, hey, programmer's can't agree on definitions at the best of times, that is not the definition that was used earlier. And is not the definition presented by the XP gang. John Carmack of Doom fame seems to share your definition, suggesting that attempts to plan architecture in advance will only come to bite you, but I'm not sure he is an XP subscriber and he certainly wasn't involved in C3.
      - PH95VuimJjqBqy 3y ago
        oh yeah, you're right, what the XP guys meant was "spend all your time building the architecture with all kinds of extension points just don't implement them... YAGNI!". It's a mis-interpretation and it's not a reasonable one either.
        randomdata 3y ago
        Pretty much. Central to the YAGNI message is ensuring that your design brings test coverage to help you build the things you need when you need it. Kent Beck is credited with having invented TDD, so of course that's at the heart of their theorem. You need those extension points to keep your tests sane. They come naturally as part of the testing process.
        PH95VuimJjqBqy 3y ago
        https://dhh.dk/2014/test-induced-design-damage.html https://dhh.dk/2014/test-induced-design-damage.html
        randomdata 3y ago
        It's always strange when someone on a discussion forum defers to someone else for their thoughts. Why even bother? It's even stranger when the deferral isn't even relevant. Stranger still, the premise appears to be made up. I can find no mention of "Code that's hard to test in isolation is poorly designed" anywhere on the internet other than that blog post and another blog that cites DHH. Beck's insight with TDD, over the testing that came before it, was really just that if you write the test first then you have certainty that the test fails. If you are writing tests for code that you have already written, there is no way to know if your test passes because your code is conformant or because there is a bug in your test. But, whether your write your tests first or last, you do need extension points to keep your tests sane. Rails is no exception. In fact, I would argue Rails' success was directly related to it leaning into testing and it showing developers what extension points are most relevant for web applications as a result. Before Rails came along, throwing MySQL calls haphazardly into the middle of the HTML was the norm.

PH95VuimJjqBqy 3y ago

YAGNI is more about design than implementation. It's about worrying about future concerns rather than what you know you need right now. The truth is in the middle, sometimes you need to design for the future and sometimes you don't. Often designing for the future just means making sure you haven't designed yourself into a corner rather than being able to fully deal with the future but that's a nuance most people miss.

randomdata 3y ago
> YAGNI is more about design than implementation Not as it seems to be usually defined, but I agree that programmers are bad for not sharing a common nomenclature. We can't even agree what something as simple as enums are. So, no doubt that there are camps who hold that perspective. enterprise_cog clearly comes from the "don't implement", not "don't design" definition, though.
- PH95VuimJjqBqy 3y ago
  "you aint gonna need it" can be clarified as "you aint gonna need all those extension points". it can also mean you don't need functionality you're not using, including implementations for those extension points.
  - randomdata 3y ago
    While I accept your definition, because, hey, programmer's can't agree on definitions at the best of times, that is not the definition that was used earlier. And is not the definition presented by the XP gang. John Carmack of Doom fame seems to share your definition, suggesting that attempts to plan architecture in advance will only come to bite you, but I'm not sure he is an XP subscriber and he certainly wasn't involved in C3.
    - PH95VuimJjqBqy 3y ago
      oh yeah, you're right, what the XP guys meant was "spend all your time building the architecture with all kinds of extension points just don't implement them... YAGNI!". It's a mis-interpretation and it's not a reasonable one either.
      - randomdata 3y ago
        Pretty much. Central to the YAGNI message is ensuring that your design brings test coverage to help you build the things you need when you need it. Kent Beck is credited with having invented TDD, so of course that's at the heart of their theorem. You need those extension points to keep your tests sane. They come naturally as part of the testing process.
        PH95VuimJjqBqy 3y ago
        https://dhh.dk/2014/test-induced-design-damage.html https://dhh.dk/2014/test-induced-design-damage.html
        randomdata 3y ago
        It's always strange when someone on a discussion forum defers to someone else for their thoughts. Why even bother? It's even stranger when the deferral isn't even relevant. Stranger still, the premise appears to be made up. I can find no mention of "Code that's hard to test in isolation is poorly designed" anywhere on the internet other than that blog post and another blog that cites DHH. Beck's insight with TDD, over the testing that came before it, was really just that if you write the test first then you have certainty that the test fails. If you are writing tests for code that you have already written, there is no way to know if your test passes because your code is conformant or because there is a bug in your test. But, whether your write your tests first or last, you do need extension points to keep your tests sane. Rails is no exception. In fact, I would argue Rails' success was directly related to it leaning into testing and it showing developers what extension points are most relevant for web applications as a result. Before Rails came along, throwing MySQL calls haphazardly into the middle of the HTML was the norm.