4 ms·

>There is a large continuum of various ways you can make decisions in between the two extremes of "YAGNI!" and "be as general as possible". But, isn't the poin

>There is a large continuum of various ways you can make decisions in between the two extremes of "YAGNI!" and "be as general as possible". But, isn't the point of Yagni that there is not such a large continuum? Isn't the argument that attempting to anticipate the future to any degree is generally a waste of time? Once you go beyond solving the problem at hand, you've jumped the shark. My experience has shown me time and again that future planning seldom pays off, and even then in small ways. I come out far better keeping things as simple as possible, as future changes also tend to be simpler. >But in most cases you're writing something that will need to be maintained and have more features added over time, and in that case, you have a variety of architectural decisions to make... I don't know that it requires making "architectual decisions" as much as following generally good design principles and keeping your couplings reasonably loose.

Silhouette 11y ago
But, isn't the point of Yagni that there is not such a large continuum? Isn't the argument that attempting to anticipate the future to any degree is generally a waste of time? That is the argument, but that doesn't make it true. I don't know that it requires making "architectual decisions" as much as following generally good design principles and keeping your couplings reasonably loose. Aren't these going to give much the same result in practice? But if the YAGNI advocates are correct and we can't usefully predict the future at all, how can you judge things like where to put your module boundaries and limit coupling?
- unclebucknasty 11y ago
  >That is the argument, but that doesn't make it true. My comment was addressing its parent's assertion that Yagni fits on a "continuum". It's a "kind of pregnant" notion in my view. Either you're following Yagni or you're not. >Aren't these going to give much the same result in practice? It's probably more the same in theory. But, in practice, it's the difference between, say, simply minding separation of concerns versus attempting to develop a full "framework" based on attempts to predict the future, then implementing the solution to the current problem in that framework. >how can you judge things like where to put your module boundaries and limit coupling Concepts like DRY, loose coupling, encapsulation of business logic, MVC, and other design principles stand independent of any particular application. For instance, I can't recall an application I've developed wherein it wasn't clear where to separate responsibilities (i.e. impose boundaries) for the current problem. These separations are generally applicable to future iterations.
  - Silhouette 11y ago
    Either you're following Yagni or you're not. That much I agree with. What I would dispute is the implication, typical of many pro-YAGNI posters in this thread and elsewhere, that the alternative to YAGNI is somehow diving in and developing everything up-front without reference to the relative risks of requirements changing vs. incurring additional costs by delaying. That is a false dichotomy. For instance, I can't recall an application I've developed wherein it wasn't clear where to separate responsibilities (i.e. impose boundaries) for the current problem. These separations are generally applicable to future iterations. I suspect this is where our experience differs. To me, 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. However, if your basic premise is that you can't tell anything in advance about what your future requirements might be, you might model the current known situation in all kinds of different ways, but some will be much more future-proof than others. Consider the old chestnut of modelling bank accounts. If you only have to model a balance on a single account, you can have some data structure that stores the balance and some functions to increase or decrease it. As soon as you need to model transfers between accounts, it turns out that the above is a very unhelpful data model, and your emphasis on single accounts was a poor choice. Even the most basic assumptions about likely future applications would have led to a more useful path, but if you follow YAGNI you have to start with a single-account model and then follow an onerous migration procedure precisely when you need to work with multiple accounts for the first time.
    - unclebucknasty 11y ago
      >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

But, isn't the point of Yagni that there is not such a large continuum? Isn't the argument that attempting to anticipate the future to any degree is generally a waste of time? That is the argument, but that doesn't make it true. I don't know that it requires making "architectual decisions" as much as following generally good design principles and keeping your couplings reasonably loose. Aren't these going to give much the same result in practice? But if the YAGNI advocates are correct and we can't usefully predict the future at all, how can you judge things like where to put your module boundaries and limit coupling?

unclebucknasty 11y ago
>That is the argument, but that doesn't make it true. My comment was addressing its parent's assertion that Yagni fits on a "continuum". It's a "kind of pregnant" notion in my view. Either you're following Yagni or you're not. >Aren't these going to give much the same result in practice? It's probably more the same in theory. But, in practice, it's the difference between, say, simply minding separation of concerns versus attempting to develop a full "framework" based on attempts to predict the future, then implementing the solution to the current problem in that framework. >how can you judge things like where to put your module boundaries and limit coupling Concepts like DRY, loose coupling, encapsulation of business logic, MVC, and other design principles stand independent of any particular application. For instance, I can't recall an application I've developed wherein it wasn't clear where to separate responsibilities (i.e. impose boundaries) for the current problem. These separations are generally applicable to future iterations.
- Silhouette 11y ago
  Either you're following Yagni or you're not. That much I agree with. What I would dispute is the implication, typical of many pro-YAGNI posters in this thread and elsewhere, that the alternative to YAGNI is somehow diving in and developing everything up-front without reference to the relative risks of requirements changing vs. incurring additional costs by delaying. That is a false dichotomy. For instance, I can't recall an application I've developed wherein it wasn't clear where to separate responsibilities (i.e. impose boundaries) for the current problem. These separations are generally applicable to future iterations. I suspect this is where our experience differs. To me, 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. However, if your basic premise is that you can't tell anything in advance about what your future requirements might be, you might model the current known situation in all kinds of different ways, but some will be much more future-proof than others. Consider the old chestnut of modelling bank accounts. If you only have to model a balance on a single account, you can have some data structure that stores the balance and some functions to increase or decrease it. As soon as you need to model transfers between accounts, it turns out that the above is a very unhelpful data model, and your emphasis on single accounts was a poor choice. Even the most basic assumptions about likely future applications would have led to a more useful path, but if you follow YAGNI you have to start with a single-account model and then follow an onerous migration procedure precisely when you need to work with multiple accounts for the first time.
  - unclebucknasty 11y ago
    >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.