YAGNI creates problems.
It doesn't say you should not consider future considerations in your design. In fact, it suggests that you should design your software to be as accommodating as possible, most notably by ensuring testing is core to your design to assist you when the time for change comes. The other poster you refer to and YAGNI seem to be in alignment.
The truth is in the middle, sometimes you need to design for the future and sometimes you don't. Often designing for the future just means making sure you haven't designed yourself into a corner rather than being able to fully deal with the future but that's a nuance most people miss.
Not as it seems to be usually defined, but I agree that programmers are bad for not sharing a common nomenclature. We can't even agree what something as simple as enums are. So, no doubt that there are camps who hold that perspective. enterprise_cog clearly comes from the "don't implement", not "don't design" definition, though.
it can also mean you don't need functionality you're not using, including implementations for those extension points.
John Carmack of Doom fame seems to share your definition, suggesting that attempts to plan architecture in advance will only come to bite you, but I'm not sure he is an XP subscriber and he certainly wasn't involved in C3.
It's a mis-interpretation and it's not a reasonable one either.
You need those extension points to keep your tests sane. They come naturally as part of the testing process.
It's even stranger when the deferral isn't even relevant.
Stranger still, the premise appears to be made up. I can find no mention of "Code that's hard to test in isolation is poorly designed" anywhere on the internet other than that blog post and another blog that cites DHH.
Beck's insight with TDD, over the testing that came before it, was really just that if you write the test first then you have certainty that the test fails. If you are writing tests for code that you have already written, there is no way to know if your test passes because your code is conformant or because there is a bug in your test.
But, whether your write your tests first or last, you do need extension points to keep your tests sane. Rails is no exception. In fact, I would argue Rails' success was directly related to it leaning into testing and it showing developers what extension points are most relevant for web applications as a result. Before Rails came along, throwing MySQL calls haphazardly into the middle of the HTML was the norm.
What's going to happen is that over time you'll eventually have the experience to understand what's being described here.
Because it turns out there's a lot of things that young people find weird that they later understand.
I figured.
> What's going to happen is that over time you'll eventually have the experience to understand what's being described here.
I've been around long enough to be aware of the surface level motivation – accepting the point without defensive dismissal would cause harm to your ego. I just don't get the appeal. Who cares about the ego? If you have no thoughts to share, why post anything? Surely if DHH wants to share his thoughts here, he can come here himself?
> Because it turns out there's a lot of things that young people find weird that they later understand.
Curiously, older people almost universally state that getting older means caring about the ego less and less. Maybe what you are trying to say here is that you are still too young to understand that? Fair enough.
or to quote a meme.
transparent poster is transparent.
It is recognized that you did answer the question. You said as a defence mechanism. That is understood. But the follow up is asking on deeper level: What needs to be defended against, exactly? What is that you think your ego going to do to you if you don't put up these defences?
seriously man, nothing you say matters anymore as you don't have the experience necessary to even begin to understand what I'm saying.
just stop.
The last coherent thought you had was an assertion that YAGNI may include not implementing extension points. But then DHH, while admittedly starting with a made up premise that made no sense, came along and obliterated that notion by the end, detailing how extension points – what he calls model, integration, and system – are necessary to keep tests sane.
And, since YANGI emphasizes testing, we can be assured it actually does include implementing integration points.