6 ms·

Perhaps the biggest fail of XP and C3 was the YAGNI philosophy. As it turns out, in many complex domains, you ARE going to need it, so you should factor that i

Perhaps the biggest fail of XP and C3 was the YAGNI philosophy. As it turns out, in many complex domains, you ARE going to need it, so you should factor that into your design sooner rather than later. This is also why many consulting lead projects fail, because the developers do not understand the complexities of the domain. Not everything is a CRUD website.

enterprise_cog 3y ago
YAGNI is about not implementing features until they are needed. It’s not about ignoring the complexities of the domain. You can adhere to the principle while still designing a system that acknowledges the complexities but defers implementation until it is needed.
- PH95VuimJjqBqy 3y ago
  I have no horse in this race but I believe what the other poster was saying is that you might not need it but you should still think about it and decide if you should factor it into your designs. YAGNI creates problems.
  - deleted 3y ago
    [deleted]
  - randomdata 3y ago
    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.
matchagaucho 3y ago
YAGNI is a conscious and iterative task prioritization process. From a Pareto perspective, it just means to focus on the 20% of functionality that provides 80% of the value first. That's not to say the other 80% of requests should be ignored. But instead well documented and groomed in a backlog.
- Scubabear68 3y ago
  In practice, YAGNI works out exactly how C3 ended up. Your architecture and design ends up myopic and short sighted, and gets overwhelmed by deferring complexity that could have been dealt with adequately early on, it is much harder to retrofit back onto an existing code base. Fowler means it literally. He had examples published on Artima.com years ago where he gives examples of hard coding things left and right and adding better support “only when you absolutely need it”. To be clear I am not arguing for big design up front. I am arguing to keep an eyeball on your roadmap, and that is not only OK to anticipate the future but maybe do some small amount of work to make the future work easier. The fallacy of “You Ain’t Gonna Need It” is that you so very often do, and the developers down the road are cursing out the devs who ignored the future.
  - hirvi74 3y ago
    "You Are Gonna Need It" is the YANGI I live. I also feel the same about "premature optimization," but that might just be due to my personality.
    - randomdata 3y ago
      If you subscribe to "You Are Gonna Need It", how do you ever get around to shipping software if you are always implementing the things that are fun, but unnecessary, and not focusing on the things that are needed to progress? The "premature optimization" thing warned against making code hard to read/debug for the sake of performance in areas where performance is unlikely to ever be a concern. If you don't ship software, it is understandable this is isn't much of a problem. Although I'm not sure how applicable that really is today anyway. The tools have changed dramatically. Often you want to make your code as readable/debuggable as possible as that also gives the best chance for the compiler to find the optimizations. These days, if you try to get fancy, you'll probably make the performance worse.

enterprise_cog 3y ago

YAGNI is about not implementing features until they are needed. It’s not about ignoring the complexities of the domain. You can adhere to the principle while still designing a system that acknowledges the complexities but defers implementation until it is needed.

PH95VuimJjqBqy 3y ago
I have no horse in this race but I believe what the other poster was saying is that you might not need it but you should still think about it and decide if you should factor it into your designs. YAGNI creates problems.
- deleted 3y ago
  [deleted]
- randomdata 3y ago
  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.

matchagaucho 3y ago

YAGNI is a conscious and iterative task prioritization process. From a Pareto perspective, it just means to focus on the 20% of functionality that provides 80% of the value first. That's not to say the other 80% of requests should be ignored. But instead well documented and groomed in a backlog.

Scubabear68 3y ago
In practice, YAGNI works out exactly how C3 ended up. Your architecture and design ends up myopic and short sighted, and gets overwhelmed by deferring complexity that could have been dealt with adequately early on, it is much harder to retrofit back onto an existing code base. Fowler means it literally. He had examples published on Artima.com years ago where he gives examples of hard coding things left and right and adding better support “only when you absolutely need it”. To be clear I am not arguing for big design up front. I am arguing to keep an eyeball on your roadmap, and that is not only OK to anticipate the future but maybe do some small amount of work to make the future work easier. The fallacy of “You Ain’t Gonna Need It” is that you so very often do, and the developers down the road are cursing out the devs who ignored the future.
- hirvi74 3y ago
  "You Are Gonna Need It" is the YANGI I live. I also feel the same about "premature optimization," but that might just be due to my personality.
  - randomdata 3y ago
    If you subscribe to "You Are Gonna Need It", how do you ever get around to shipping software if you are always implementing the things that are fun, but unnecessary, and not focusing on the things that are needed to progress? The "premature optimization" thing warned against making code hard to read/debug for the sake of performance in areas where performance is unlikely to ever be a concern. If you don't ship software, it is understandable this is isn't much of a problem. Although I'm not sure how applicable that really is today anyway. The tools have changed dramatically. Often you want to make your code as readable/debuggable as possible as that also gives the best chance for the compiler to find the optimizations. These days, if you try to get fancy, you'll probably make the performance worse.