7 ms·

I think this is trying to simplify an already simple idea, succinctly: "Optimize your time intelligently". Rules of thumb (like YAGNI) may not be correct, depe

I think this is trying to simplify an already simple idea, succinctly: "Optimize your time intelligently". Rules of thumb (like YAGNI) may not be correct, depending on the situation. Estimating time complexity is hard, so deferring development defers mistakes in estimation. Great. However, if you know that you have a 90% chance of needing a feature in 6 months, and it will be 2x easier to build now when you have a team actively engaged on a similar project, then YAGNI is the wrong choice. Counter examples exist, like you are in such an extreme environment where (like first month of a startup) the opportunity cost of those programmers is very high. Regardless, I would ask "Is this the best use of time now" rather than "YAGNI".

pbreit 11y ago
The whole point of the article is that you're wrong. And I tend to agree. Not trying to predict feature needs down the road is extremely empowering. Building you're unnecessary feature now is just as likely to increase the complexity of everything in the future as it is to be 2x easier to build now. YAGNI dramatically simplifies the answering of your question: if it's not needed now, don't do it.
- chris_va 11y ago
  Using your example: Let's say I know it will cause a complexity burden in the future. Shouldn't we ask if that complexity burden and opportunity cost are outweighed by the expected benefits, rather than rather than simply relying on a simplistic rule of thumb of always deferring? People are capable of (which, to your point is not the same as being consistently good at) making good calculations as to what is a waste of time.
  - pbreit 11y ago
    Quite a contrived scenario, but, no. Just build the feature you need and move on. No need over-analyzing. See? I didn't have to get trapped in your pretty much un-answerable pondering. Following the rule crystallizes a lot of decision-making. It's very empowering when you don't have too many objectors.
    - chris_va 11y ago
      And yet, you might take longer to finish the project than someone else. Just because something is freeing doesn't mean it's a good idea. Nor does it mean it is a bad idea, it just means it's an uninformed idea. Obviously it's suboptimal to ponder an un-answerable question. That doesn't mean it you shouldn't spend 1 minute thinking about it.
  - mkozlows 11y ago
    First, let's disabuse you of the notion that you "know" anything about the future. You can only guess about the future.
    - Silhouette 11y ago
      Then you need better management on your development team. A project manager who can't give at least an intelligent assessment of the risk/likelihood of key features changing some way ahead is about as useful to a programmer as a programmer who can't give an estimate of how long it will take to implement a simple feature within an order of magnitude to a project manager. I am still waiting to encounter this hypothetical project where the future always deviates significantly from any reasonable prediction with negligible overhead. On the contrary, my experience has been that any successful project team probably has at least a reasonable idea of where the development is going some way ahead and that confidence usually increases the closer you get. While that level of confidence may not justify immediate full development of future features that aren't 100% known to be required, it does often let you make reasonable allowances for likely future work in terms of project architecture so you don't back yourself into a corner unnecessarily. As chris_va has been saying, it always comes down to risks and confidence and cost/benefit analysis, like any business decision. You can repeat "You ain't gonna need it" until you're blue in the face, but that doesn't make it true. Much of the time, you will in reality need a feature that everyone has been talking about for six months already and your sales guys have been promising to customers for seven of them. In fact, any development team that really does dwell extensively on development work they aren't actually going to need later should probably question the general competence of their management. Responding effectively to changing requirements does not require sticking your head in the sand, and it certainly doesn't require making ad-hoc changes to design/architecture at any level you feel like for every new feature.
      - mkozlows 11y ago
        It's possible you have worked in a world where there really is requirements-level (which means business-process level) stability over a year. I never have, and I don't think that describes most businesses out there. Given that, writing software that is responsive to the needs of the business must accept that change in unknown directions is a certainty. Now, does that mean that you literally never know anything at all about what will come up? No, of course not. Sometimes you'll see a thing coming for nine months, and it'll actually land just like everyone thought. But the point of YAGNI -- and the point Fowler made so well in his essay -- is that you still don't need to do your chin-stroking calculations and elaborate plannings on whether you should build for that now. Because building for it now has a real guaranteed cost (the direct cost of building it, the opportunity cost of the value you didn't deliver by building something more immediately necessary, the technical debt of maintaining it in the face of other evolution until you get to the time when it actually is needed) that strongly argues against building it even if it will happen. In any other field, this is really obvious. If a contractor is building a house, and they say "you know, we've already got the cement-pouring team here, we know we're going to build a dozen houses this year, why don't we just build all twelve basements right now" they're going to be slapped down quickly -- that's absurd, don't tie-down all those resources speculatively, and anyway if you do that, the house you're building is going to be late, let's focus on what's needed. And that's true even if the contractor was totally right about needing those dozen houses (and exactly which dozen, and exactly what they should look like). That you're probably going to be wrong to one degree or another (even features that end up happening often look significantly different when they happen than they did in prospect, months out) makes the YAGNI equation that much more compelling; but even without that, the numbers rarely are going to come down in favor of speculative construction for hypotheticals. So, yes, you need to weigh the benefits against the costs. It just turns out that this is nearly always a calculation that leads inexorably to one result: Don't do it until you actually need to do it.
  - lmm 11y ago
    In principle I'd agree. In practice, I think people consistently overestimate the value of planning, and my experience is so overwhelmingly in favour of not planning that I don't think it's worth spending even a small amount of time (which is a nonzero cost) trying to calculate whether this is one of the one-in-a-million cases where it would be worthwhile.
    - robmcm 11y ago
      If I had one hour to save the world, I would spend 55 minutes defining the problem and only five minutes finding the solution. –Einstein, Albert
- jonahx 11y ago
  Making decisions by flipping a coin also simplifies them dramatically -- it doesn't mean it's optimal. I think your reply captures both the appeal and the danger of YAGNI well. While I think it's often a good heuristic in practice, it is just a heuristic and it can be badly abused in cases where future needs can be accurately predicted today. Saying "But can they really ever be predicted?" is a cop out imo, because in some cases the answer is yes.
  - pbreit 11y ago
    But even if they can be predicted, the benefit of doing them now is difficult or impossible to quantify. But the cost is unambiguous.
    - jonahx 11y ago
      Not really. Sometimes you know the cost right now will be less than a few hours. The future cost of the same changes will be at least that, with a very high liklihood (sometimes, a near certainty) of being 2-10x that. Are you really arguing that this rule of thumb leads to optimal decisions 100% of the time? Because that is clearly untrue. If you want to make the argument that allowing exceptions to the rule opens up a pandora's box that is ultimately worse than just always following the rule blindly, okay. I think I'd still disagree, but it's at least a defensible argument.
      - pbreit 11y ago
        A key aspect of the rule is that it eliminates low value disagreements like this one. First, you're completely forgetting the cost of (unnecessary) code in the system. And you're still making indefensible assertions (2-10x).
sbov 11y ago
It's still not that straightforward. What if features X, Y, and Z needed in < 6 months each are 2x harder to code because of the planning of feature B that has a 90% chance of being needed after them? You potentially "saved" time by doing feature B but depending upon the total time to code feature X, Y, and Z, 10% of the extra difficulty in features X Y and Z may still outstrip 90% of the time saved in feature B. Nevermind that as feature B goes unused for 6 months bugs and incompatibilities may creep in. Eventually what you wrote for feature B may be mostly useless when you finally get around to actually needing it. I have had this happen on projects before.
- chris_va 11y ago
  I agree. Projects should not be scheduled in isolation. Delay may be a great idea, or a terrible idea. Sometimes prediction is easy, sometimes it is not. Trying to oversimplify the decision making is a mistake.
- deleted 11y ago
  [deleted]

pbreit 11y ago

The whole point of the article is that you're wrong. And I tend to agree. Not trying to predict feature needs down the road is extremely empowering. Building you're unnecessary feature now is just as likely to increase the complexity of everything in the future as it is to be 2x easier to build now. YAGNI dramatically simplifies the answering of your question: if it's not needed now, don't do it.

chris_va 11y ago
Using your example: Let's say I know it will cause a complexity burden in the future. Shouldn't we ask if that complexity burden and opportunity cost are outweighed by the expected benefits, rather than rather than simply relying on a simplistic rule of thumb of always deferring? People are capable of (which, to your point is not the same as being consistently good at) making good calculations as to what is a waste of time.
- pbreit 11y ago
  Quite a contrived scenario, but, no. Just build the feature you need and move on. No need over-analyzing. See? I didn't have to get trapped in your pretty much un-answerable pondering. Following the rule crystallizes a lot of decision-making. It's very empowering when you don't have too many objectors.
  - chris_va 11y ago
    And yet, you might take longer to finish the project than someone else. Just because something is freeing doesn't mean it's a good idea. Nor does it mean it is a bad idea, it just means it's an uninformed idea. Obviously it's suboptimal to ponder an un-answerable question. That doesn't mean it you shouldn't spend 1 minute thinking about it.
- mkozlows 11y ago
  First, let's disabuse you of the notion that you "know" anything about the future. You can only guess about the future.
  - Silhouette 11y ago
    Then you need better management on your development team. A project manager who can't give at least an intelligent assessment of the risk/likelihood of key features changing some way ahead is about as useful to a programmer as a programmer who can't give an estimate of how long it will take to implement a simple feature within an order of magnitude to a project manager. I am still waiting to encounter this hypothetical project where the future always deviates significantly from any reasonable prediction with negligible overhead. On the contrary, my experience has been that any successful project team probably has at least a reasonable idea of where the development is going some way ahead and that confidence usually increases the closer you get. While that level of confidence may not justify immediate full development of future features that aren't 100% known to be required, it does often let you make reasonable allowances for likely future work in terms of project architecture so you don't back yourself into a corner unnecessarily. As chris_va has been saying, it always comes down to risks and confidence and cost/benefit analysis, like any business decision. You can repeat "You ain't gonna need it" until you're blue in the face, but that doesn't make it true. Much of the time, you will in reality need a feature that everyone has been talking about for six months already and your sales guys have been promising to customers for seven of them. In fact, any development team that really does dwell extensively on development work they aren't actually going to need later should probably question the general competence of their management. Responding effectively to changing requirements does not require sticking your head in the sand, and it certainly doesn't require making ad-hoc changes to design/architecture at any level you feel like for every new feature.
    - mkozlows 11y ago
      It's possible you have worked in a world where there really is requirements-level (which means business-process level) stability over a year. I never have, and I don't think that describes most businesses out there. Given that, writing software that is responsive to the needs of the business must accept that change in unknown directions is a certainty. Now, does that mean that you literally never know anything at all about what will come up? No, of course not. Sometimes you'll see a thing coming for nine months, and it'll actually land just like everyone thought. But the point of YAGNI -- and the point Fowler made so well in his essay -- is that you still don't need to do your chin-stroking calculations and elaborate plannings on whether you should build for that now. Because building for it now has a real guaranteed cost (the direct cost of building it, the opportunity cost of the value you didn't deliver by building something more immediately necessary, the technical debt of maintaining it in the face of other evolution until you get to the time when it actually is needed) that strongly argues against building it even if it will happen. In any other field, this is really obvious. If a contractor is building a house, and they say "you know, we've already got the cement-pouring team here, we know we're going to build a dozen houses this year, why don't we just build all twelve basements right now" they're going to be slapped down quickly -- that's absurd, don't tie-down all those resources speculatively, and anyway if you do that, the house you're building is going to be late, let's focus on what's needed. And that's true even if the contractor was totally right about needing those dozen houses (and exactly which dozen, and exactly what they should look like). That you're probably going to be wrong to one degree or another (even features that end up happening often look significantly different when they happen than they did in prospect, months out) makes the YAGNI equation that much more compelling; but even without that, the numbers rarely are going to come down in favor of speculative construction for hypotheticals. So, yes, you need to weigh the benefits against the costs. It just turns out that this is nearly always a calculation that leads inexorably to one result: Don't do it until you actually need to do it.
- lmm 11y ago
  In principle I'd agree. In practice, I think people consistently overestimate the value of planning, and my experience is so overwhelmingly in favour of not planning that I don't think it's worth spending even a small amount of time (which is a nonzero cost) trying to calculate whether this is one of the one-in-a-million cases where it would be worthwhile.
  - robmcm 11y ago
    If I had one hour to save the world, I would spend 55 minutes defining the problem and only five minutes finding the solution. –Einstein, Albert
jonahx 11y ago
Making decisions by flipping a coin also simplifies them dramatically -- it doesn't mean it's optimal. I think your reply captures both the appeal and the danger of YAGNI well. While I think it's often a good heuristic in practice, it is just a heuristic and it can be badly abused in cases where future needs can be accurately predicted today. Saying "But can they really ever be predicted?" is a cop out imo, because in some cases the answer is yes.
- pbreit 11y ago
  But even if they can be predicted, the benefit of doing them now is difficult or impossible to quantify. But the cost is unambiguous.
  - jonahx 11y ago
    Not really. Sometimes you know the cost right now will be less than a few hours. The future cost of the same changes will be at least that, with a very high liklihood (sometimes, a near certainty) of being 2-10x that. Are you really arguing that this rule of thumb leads to optimal decisions 100% of the time? Because that is clearly untrue. If you want to make the argument that allowing exceptions to the rule opens up a pandora's box that is ultimately worse than just always following the rule blindly, okay. I think I'd still disagree, but it's at least a defensible argument.
    - pbreit 11y ago
      A key aspect of the rule is that it eliminates low value disagreements like this one. First, you're completely forgetting the cost of (unnecessary) code in the system. And you're still making indefensible assertions (2-10x).

sbov 11y ago

It's still not that straightforward. What if features X, Y, and Z needed in < 6 months each are 2x harder to code because of the planning of feature B that has a 90% chance of being needed after them? You potentially "saved" time by doing feature B but depending upon the total time to code feature X, Y, and Z, 10% of the extra difficulty in features X Y and Z may still outstrip 90% of the time saved in feature B. Nevermind that as feature B goes unused for 6 months bugs and incompatibilities may creep in. Eventually what you wrote for feature B may be mostly useless when you finally get around to actually needing it. I have had this happen on projects before.

chris_va 11y ago
I agree. Projects should not be scheduled in isolation. Delay may be a great idea, or a terrible idea. Sometimes prediction is easy, sometimes it is not. Trying to oversimplify the decision making is a mistake.
deleted 11y ago
[deleted]