I build things with my hands. The human behind Shift - https://laravelshift.com, master of Git - https://gettinggit.com, and author of "BaseCode" - https://basecodefieldguide.com
This is one of those things that's impossible to test and therefore prove either side of the argument. From my perspective, the long-term savings by not assuming a particular design pattern and having to rip it out or maintain it is worth the short-term lose in rewriting a few lines of code.
Nevertheless, I do agree that YAGNI is not about intentionally handicapping your ability to write code.
I feel that the approach should be to consider how you need your tests to provide feedback. If I have a pattern or abstraction in mind ahead of time, it's not because I've never used it before. By writing tests assuming the abstraction, I can get feedback about it faster.
When I say that the rule seems dogmatic, it feels like the "simple rules" that we talk about driving TDD are far too simplified. They lead people to think that you have to waste time writing the simplest code possible, then once you get to refactoring you have free-reign to do whatever you need. It seems to me that everyone is better off if you take a more pragmatic approach to where you're willing to start the process.
As long as your tests help you decide if your implementation is appropriate, it shouldn't matter if the idea of the abstraction came first.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is one of those things that's impossible to test and therefore prove either side of the argument. From my perspective, the long-term savings by not assuming a particular design pattern and having to rip it out or maintain it is worth the short-term lose in rewriting a few lines of code.
Nevertheless, I do agree that YAGNI is not about intentionally handicapping your ability to write code.
I feel that the approach should be to consider how you need your tests to provide feedback. If I have a pattern or abstraction in mind ahead of time, it's not because I've never used it before. By writing tests assuming the abstraction, I can get feedback about it faster.
When I say that the rule seems dogmatic, it feels like the "simple rules" that we talk about driving TDD are far too simplified. They lead people to think that you have to waste time writing the simplest code possible, then once you get to refactoring you have free-reign to do whatever you need. It seems to me that everyone is better off if you take a more pragmatic approach to where you're willing to start the process.
As long as your tests help you decide if your implementation is appropriate, it shouldn't matter if the idea of the abstraction came first.