3 ms·

>implication...the alternative to YAGNI is somehow diving in and developing everything up-front without reference to... I don't think that's the dichotomy that

>implication...the alternative to YAGNI is somehow diving in and developing everything up-front without reference to... I don't think that's the dichotomy that's being presented, nor do I think it would matter if it was. That is, one doesn't have to go to that extreme to incur the downside of a "non-YAGNI" approach. It's very easy to have contemplation of future features negatively impact a project. >one reasonable guideline for modular design and separation of concerns is that each module should roughly correspond to a unit of change, in the sense that a change in requirements would ideally affect a single module without interfering elsewhere in the system Wow. I think that's exceedingly difficult to pull off and trying to design in such a way itself seems tremendously burdensome to the project out of the gate. It also seems that it would tightly couple the code with business requirements in such a way that change actually guarantees maximum impact to the code. Because, rules don't change in a neat, stovepiped way. So, when they change, cross-cut, overlap, etc., then all of your modularization goes right out of the window. So, interestingly, given that approach, it probably would make it more important to anticipate future changes, because your code will be less insulated from those changes! >modelling bank accounts Thanks for bringing this down from the abstract. But, this is where generally good design can help. If you have your debit and credit functionality neatly encapsulated, plus a good overall model for chaining/demarcating transactions within your app, etc., then you don't need to rip apart your entire model to support transfers. In fact, I'd say you have a good head start.

Silhouette 11y ago
It's very easy to have contemplation of future features negatively impact a project. But it's also very easy to have failure to contemplate future features negatively impact a project. This doesn't get us anywhere. I think that's exceedingly difficult to pull off and trying to design in such a way itself seems tremendously burdensome to the project out of the gate. But again, you have to design some way, unless you're proposing literally a totally organic design where even things like basic modular design are considered completely unnecessary unless justified by changes required right now. As soon as you are designing some specific way, you are necessarily making choices, and I would argue for making the best choices you can given the information you have available at the time. That may mean you don't have enough confidence in some particular requirement to justify working on it yet, or it may not. If you have your debit and credit functionality neatly encapsulated, plus a good overall model for chaining/demarcating transactions within your app, etc., then you don't need to rip apart your entire model to support transfers. But where did that good overall model you mentioned come from if you weren't anticipating potential future needs to some extent?
- unclebucknasty 11y ago
  >But it's also very easy to have failure to contemplate future features negatively impact a project. Perhaps, but in the former case you guarantee an impact to the project. And, empirically speaking, the odds are that impact will be negative. Trying to design for some unknown future is more likely to get you off the rails than designing well to known requirements. >unless you're proposing literally a totally organic design where even things like basic modular design are considered completely unnecessary Well, "modular" is such an amorphous word. Building a domain model and other functionality around current requirements will yield some degree of modularization. I'm suggesting that such modularization should tie back into the actors and objects dictated by current requirements, and is more at the programmatic level. It's horizontal (relative to requirements). This, as opposed to a vertical approach that attempts to stovepipe individual use cases into modules. The latter scenario can lead to more pain when requirements change. I sincerely believe that may be why you find it so important to anticipate future changes--because you've totally pegged your design to a modularization scheme that demands your requirements stay within neat boundaries. So, it's really important that you define those boundaries well from the outset, or you may face some serious re-work. >But where did that good overall model you mentioned come from if you weren't anticipating potential future needs to some extent? But that's really my point: good design practices in themselves do anticipate the future to a significant extent. That is, a system that is well-modeled with good separation of concerns is more flexible, less coupled and thus, more extensible. But, one need not anticipate any specific future requirements to achieve this. Just design well based on known-requirements.
  - Silhouette 11y ago
    I wonder whether we're still slightly talking at cross-purposes here. You seem to have the idea that I am somehow advocating always trying to anticipate or emphasize future requirements at the expense of what I'm doing right now, or that I'm arguing for some sort of fixed architecture or design where you need to magically know everything up front. This is certainly not what I'm trying to say. On the contrary, I adapt designs and refactor code all the time, just as many others here surely do. But I still feel that there is something rather selective in the arguments being made for any near-absolute rule about not taking expected future developments into account when designing. Whenever we talk about modular design or domain models or use cases, and whichever words we happen to use, we are always implicitly talking about making decisions of one kind or another, as evidenced by the fact that even those who are supporting YAGNI in this HN discussion are advocating things like refactoring to keep new work in good condition. Of course we can and should revisit those decisions later if we have better information and of course sometimes we will change things as a result. The only point I'm trying to make here is that I'd rather start from the position most likely to be useful, not the minimal position. To me it is all about probabilities, and perhaps unlike some here, I don't find that predicting what I'm going to need my code to do next week is some inhumanly challenging task that has a 105% failure rate with project-ending costs. On the contrary, the vast majority of the time on a real project I find things will in fact turn out exactly the way we're all expecting on those kinds of timescales, and probably pretty close a month out, while looking six months or two years ahead we probably have at best a tentative plan and just like the YAGNI fans we don't want to invest significant resources catering to hypothetical futures with a high probability of changing before we actually get there. In this context, I find it is often premature pessimisation and willful ignorance making the work that will almost always turn out to be unnecessary, not the other way around. The idea that I should discard knowledge of what is almost certainly coming next week and create more work for myself on Monday just in case something totally unexpected happens by the end of this week is bizarre to me. Maybe we've just worked on very different kinds of projects or had very different standards for the management/leadership who are making decisions on those projects.

Silhouette 11y ago

It's very easy to have contemplation of future features negatively impact a project. But it's also very easy to have failure to contemplate future features negatively impact a project. This doesn't get us anywhere. I think that's exceedingly difficult to pull off and trying to design in such a way itself seems tremendously burdensome to the project out of the gate. But again, you have to design some way, unless you're proposing literally a totally organic design where even things like basic modular design are considered completely unnecessary unless justified by changes required right now. As soon as you are designing some specific way, you are necessarily making choices, and I would argue for making the best choices you can given the information you have available at the time. That may mean you don't have enough confidence in some particular requirement to justify working on it yet, or it may not. If you have your debit and credit functionality neatly encapsulated, plus a good overall model for chaining/demarcating transactions within your app, etc., then you don't need to rip apart your entire model to support transfers. But where did that good overall model you mentioned come from if you weren't anticipating potential future needs to some extent?

unclebucknasty 11y ago
>But it's also very easy to have failure to contemplate future features negatively impact a project. Perhaps, but in the former case you guarantee an impact to the project. And, empirically speaking, the odds are that impact will be negative. Trying to design for some unknown future is more likely to get you off the rails than designing well to known requirements. >unless you're proposing literally a totally organic design where even things like basic modular design are considered completely unnecessary Well, "modular" is such an amorphous word. Building a domain model and other functionality around current requirements will yield some degree of modularization. I'm suggesting that such modularization should tie back into the actors and objects dictated by current requirements, and is more at the programmatic level. It's horizontal (relative to requirements). This, as opposed to a vertical approach that attempts to stovepipe individual use cases into modules. The latter scenario can lead to more pain when requirements change. I sincerely believe that may be why you find it so important to anticipate future changes--because you've totally pegged your design to a modularization scheme that demands your requirements stay within neat boundaries. So, it's really important that you define those boundaries well from the outset, or you may face some serious re-work. >But where did that good overall model you mentioned come from if you weren't anticipating potential future needs to some extent? But that's really my point: good design practices in themselves do anticipate the future to a significant extent. That is, a system that is well-modeled with good separation of concerns is more flexible, less coupled and thus, more extensible. But, one need not anticipate any specific future requirements to achieve this. Just design well based on known-requirements.
- Silhouette 11y ago
  I wonder whether we're still slightly talking at cross-purposes here. You seem to have the idea that I am somehow advocating always trying to anticipate or emphasize future requirements at the expense of what I'm doing right now, or that I'm arguing for some sort of fixed architecture or design where you need to magically know everything up front. This is certainly not what I'm trying to say. On the contrary, I adapt designs and refactor code all the time, just as many others here surely do. But I still feel that there is something rather selective in the arguments being made for any near-absolute rule about not taking expected future developments into account when designing. Whenever we talk about modular design or domain models or use cases, and whichever words we happen to use, we are always implicitly talking about making decisions of one kind or another, as evidenced by the fact that even those who are supporting YAGNI in this HN discussion are advocating things like refactoring to keep new work in good condition. Of course we can and should revisit those decisions later if we have better information and of course sometimes we will change things as a result. The only point I'm trying to make here is that I'd rather start from the position most likely to be useful, not the minimal position. To me it is all about probabilities, and perhaps unlike some here, I don't find that predicting what I'm going to need my code to do next week is some inhumanly challenging task that has a 105% failure rate with project-ending costs. On the contrary, the vast majority of the time on a real project I find things will in fact turn out exactly the way we're all expecting on those kinds of timescales, and probably pretty close a month out, while looking six months or two years ahead we probably have at best a tentative plan and just like the YAGNI fans we don't want to invest significant resources catering to hypothetical futures with a high probability of changing before we actually get there. In this context, I find it is often premature pessimisation and willful ignorance making the work that will almost always turn out to be unnecessary, not the other way around. The idea that I should discard knowledge of what is almost certainly coming next week and create more work for myself on Monday just in case something totally unexpected happens by the end of this week is bizarre to me. Maybe we've just worked on very different kinds of projects or had very different standards for the management/leadership who are making decisions on those projects.