For the love of god, please use some common sense when repeating mantras like "write less code." I've seen this used to justify all sorts of ridiculous shit, like dropping basic security measures (write less code! YAGNI! Why would someone try SQL injection/XSS against our site anyway?!?).
If I propose something and your thought-terminating cliche response is some form of "YAGNI," I hate you.
To be fair the author said write less _damn_ code.
Regular code, however, is fine.[1]
[1] Even better if your code is blessed.
This has been my experience too. While the concept has value, I find most people that throw the term around do so as a justification for not thinking much.
To armchair psychologize a bit, I think that enthusiastically embracing an acronym which, whatever its conceptual merits, is just so lame-sounding correlates negatively with taste, and taste correlates, albeit imperfectly, with programming skill, especially the skill of writing readable code.
It's a short, easily pronounced English word whose meaning is a nice metaphorical fit for the concept expressed by the acronym.
You can argue acronyms in general are lame, but I'm not taking that hard line.
As I say in a cousin comment, good taste is just 3rd order laziness. You're doing less by avoiding future trouble.
To armchair psychologize a bit, I think that enthusiastically embracing an acronym which, whatever its conceptual merits, is just so lame-sounding correlates negatively with taste
Wouldn't you prioritize conceptual taste over aesthetic taste? YAGNI probably sounds goofy because it was created in the late 90's. It was part of the original Extreme Programming formula. The concept is as solid as such concepts get, however.
Sure, my point was they're related (usually).
> The concept is as solid as such concepts get, however.
It's useful in many cases, yes. Solid? No. It requires far too much attention to context, and experience, to apply it wisely all the time. That is to say, YAGNI is invoked in defense of bad decisions as often as it is of good ones. That was the grandparent's point.
Sounds a little like you generally stop at the aesthetic level. The map isn't the territory, and the signals aren't the actual internal mental state of the person. Since you say "usually," how have you been accumulating data about this relationship?
It's useful in many cases, yes. Solid? No. It requires far too much attention to context, and experience, to apply it wisely all the time.
Hmmm. You should be making exactly this sort of decision all the time. The major task of a developer, as I see it after doing this for 36 years, is to pay a lot of attention to context and apply what you've learned by experience wisely. Erring on the side of caution and waiting until there's evidence you need something isn't a bad 1st order heuristic. I would label people who consistently stop at the 1st order heuristic and go no farther as "shallow."
No, it doesn't sound like that at all. You've just decided to read it that way and make an ad-hominem argument instead of engaging with the statement itself.
> Hmmm. You should be making exactly this sort of decision all the time. The major task of a developer, as I see it after doing this for 36 years, is to pay a lot of attention to context and apply what you've learned by experience wisely. Erring on the side of caution and waiting until there's evidence you need something isn't a bad 1st order heuristic. I would label people who consistently stop at the 1st order heuristic and go no farther as "shallow."
I agree with everything you said, and have not said anything that contradicts it.
It's a good heuristic. And it's only that. And lots of people apply it poorly.
Well, no. You've said a lot of things in this thread that seem to indicate that a 1st order heuristic only has value if it can be used in place of cognition. If there are more than 2 possible answers, a 1st order heuristic that was correct 40% of the time could still have value.
And lots of people apply it poorly.
Applying it properly is taking it as, "We need more evidence to justify the cost/benefit." That's conceptually more precise, though it manages to sound even more awkward than YAGNI. But from what you've been saying, it seems like "YAGNI" is simply the end of discussion.
IME, the YAGNI principle is most useful with new-ish developers who've been taught certain patterns but haven't grasped the motivation for them and so can't judge when the overhead is worth it. In Java-land we'd be talking about the old every-class-must-implement-an-interface-and-come-from-a-factory clichés. It's not that it's a bad pattern, just that until you have multiple implementations and/or a need for DI it probably isn't worth the source bloat.
In that situation I think YAGNI is exactly the right objection, and I'm not sure what would take its place if it became widely Considered Harmful.
It's incredibly mind-numbing when it's being used to justify laziness and short-sightedness. Worse, it's not exactly a misuse of the phrase, as per the original XP article:
> Always implement things when you actually need them
Security is, as an example, one of those things where you'd face a disaster if you just implemented it when you actually needed it (i.e. when an attack occurred).
YAGNI is incredibly short-sighted in situations where rectifying the situation later will be an absolute nightmare (or just impossible). An ounce of prevention is worth a pound of cure, and all that.
Good taste is just a form of 3rd order laziness.
Great line! Saved in my quotes file.
Of course, only if you actually don't need it.