4 ms·

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 outwei

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.
    - Silhouette 11y ago
      I think the difference between the pro-YAGNI crowd and the sceptics here is one of absolutism. You have immediately translated my position, which was about risk and confidence and making a cost/benefit judgement based on the best information at any given time, into an absolute one, where we know the full requirements for a project a year in advance. But that isn't what I said, or what several of the other sceptics here are saying either. To put it in your terms, we're not saying you should build 11 spare basements because you've got the concrete guys on-site today. We're saying if you're building a concrete basement then you can reasonably assume this house will also soon have external walls that will roughly match the signed-off, legally-binding planning consent, so if you don't put the rebar in before the concrete sets you're going to have a much harder time finishing the house later or may even find it is no longer cost-effective to do so because the cost of doing that preparatory work only when you're certain you need it will be very much higher.
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

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.
  - Silhouette 11y ago
    I think the difference between the pro-YAGNI crowd and the sceptics here is one of absolutism. You have immediately translated my position, which was about risk and confidence and making a cost/benefit judgement based on the best information at any given time, into an absolute one, where we know the full requirements for a project a year in advance. But that isn't what I said, or what several of the other sceptics here are saying either. To put it in your terms, we're not saying you should build 11 spare basements because you've got the concrete guys on-site today. We're saying if you're building a concrete basement then you can reasonably assume this house will also soon have external walls that will roughly match the signed-off, legally-binding planning consent, so if you don't put the rebar in before the concrete sets you're going to have a much harder time finishing the house later or may even find it is no longer cost-effective to do so because the cost of doing that preparatory work only when you're certain you need it will be very much higher.

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