4 ms·

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

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.
- lowbloodsugar 11y ago
  Except it turns out that: a) The boss has changed his mind and now we're building a pool, so we need to cut off all this f* rebar sticking out. More time to remove it, plus the cost of adding it in the first place. b) Its software, so adding the rebar is as easy as F6-refactor. You are scaring the children. Stop it with the FUD.
  - Silhouette 11y ago
    You can always come up with exceptional counter-examples in any argument about probabilities and making cost/benefit judgements. As I noted elsewhere, my experience has apparently been very different to some here, because I'm still waiting to see the project where the entire direction suddenly shifted so fundamentally that it wound up writing off significant amounts of code that was now useless. (Just for the record, I'm also still waiting to see the house where the rebar is in changed to require a pool where the planning consent stated a house was to be built, though I've seen a lot of houses with the rebar in where the walls then went up a short time later without having to rebuild the entire foundation because the rebar was already in.) I've written elsewhere in this HN discussion about a few different types of project where you can't just refactor your way out of trouble if you go too far down the wrong path. The cost of doing so can easily become more expensive than just throwing out the whole thing and starting again. This isn't FUD, it's a few decades of professional programming experience talking. They just happen not to be the same few decades that some of the other posters here have had. And as once again I seem to keep writing now, that is why it is unwise to generalise too far from personal experience or a small anecdotal base to an entire field as vast as programming.
- pbreit 11y ago
  The examples given are always so contrived. And the whole point is to eliminate all this clutter from your head so you can focus on the task at hand.
  - Silhouette 11y ago
    I don't find having varying levels of data and confidence about the likely future directions of a project to be "clutter", nor do I find they tend to complicate whatever I'm trying to develop right now. On the contrary, I often find it useful to have more context and frame of reference about what I'm doing, even though often I may choose not to act on that knowledge immediately for much the same reasons that others here are arguing for always following YAGNI. Please remember that my argument is not that you should always try to anticipate future requirements or over-engineer designs to cope with every hypothetical you can think of. My position is merely that you should weigh the costs of acting unnecessarily now against the costs of not having acted when it turned out to be useful, and make a decision according to your best estimate of how likely it is that you will benefit from following either path. YMMV, of course, and certainly sometimes the decision will be different to others.

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.

lowbloodsugar 11y ago
Except it turns out that: a) The boss has changed his mind and now we're building a pool, so we need to cut off all this f* rebar sticking out. More time to remove it, plus the cost of adding it in the first place. b) Its software, so adding the rebar is as easy as F6-refactor. You are scaring the children. Stop it with the FUD.
- Silhouette 11y ago
  You can always come up with exceptional counter-examples in any argument about probabilities and making cost/benefit judgements. As I noted elsewhere, my experience has apparently been very different to some here, because I'm still waiting to see the project where the entire direction suddenly shifted so fundamentally that it wound up writing off significant amounts of code that was now useless. (Just for the record, I'm also still waiting to see the house where the rebar is in changed to require a pool where the planning consent stated a house was to be built, though I've seen a lot of houses with the rebar in where the walls then went up a short time later without having to rebuild the entire foundation because the rebar was already in.) I've written elsewhere in this HN discussion about a few different types of project where you can't just refactor your way out of trouble if you go too far down the wrong path. The cost of doing so can easily become more expensive than just throwing out the whole thing and starting again. This isn't FUD, it's a few decades of professional programming experience talking. They just happen not to be the same few decades that some of the other posters here have had. And as once again I seem to keep writing now, that is why it is unwise to generalise too far from personal experience or a small anecdotal base to an entire field as vast as programming.
pbreit 11y ago
The examples given are always so contrived. And the whole point is to eliminate all this clutter from your head so you can focus on the task at hand.
- Silhouette 11y ago
  I don't find having varying levels of data and confidence about the likely future directions of a project to be "clutter", nor do I find they tend to complicate whatever I'm trying to develop right now. On the contrary, I often find it useful to have more context and frame of reference about what I'm doing, even though often I may choose not to act on that knowledge immediately for much the same reasons that others here are arguing for always following YAGNI. Please remember that my argument is not that you should always try to anticipate future requirements or over-engineer designs to cope with every hypothetical you can think of. My position is merely that you should weigh the costs of acting unnecessarily now against the costs of not having acted when it turned out to be useful, and make a decision according to your best estimate of how likely it is that you will benefit from following either path. YMMV, of course, and certainly sometimes the decision will be different to others.