A while back I spoke at Laracon about Practicing YAGNI. It was an honor to present in front of such a large audience at such a premiere conference....
For further actions, you may consider blocking this person and/or reporting abuse
This can very quickly be taken too far. I might add: "Abstracting external dependencies adds complexity to your project."
These are cases where YAGNI should absolutely be practiced. Eventually you have to base your application on something concrete, i.e. a particular DB engine or programming language; trying to abstract these things away completely is a waste of time.
Furthermore, excessive abstraction can make it hard or impossible to actually use a tool effectively. For example, if your ORM provides pagination but you abstract away the ORM (using "repository pattern" or some such), you now have to reimplement pagination in your application code, or pass everything through, effectively rewriting the ORMs API.
I think YAGNI is the perfect philosophy when asking things like "What if we want to switch from MySQL to MongoDB?" To wit: you are probably never going to want to do that, and if you are, it's probably cheaper overall to just do the rewrites at that point than using some hobbled db abstraction layer that provides crappy SQL support & crappy mongo support but technically "supports both."
Thanks for the food for thought!
IMHO, You should keep decoupled your domain layer from the infrastructure layer.
It's not about "What if we want to switch from MySQL to MongoDB?", it's all about of separation of concerns. For example, by applying "Dependency Inversion", it only takes a few minutes (sometimes 1, YMMV) to create a domain interface and then create the implementation in the infrastructure layer, although you know that you aren't going to change the DB next month (Be careful here, because applying this principle everywhere is an example of over engineering, we're in a separation of concerns context).
As Jason McCreary says in the article, external dependencies add useless complexity to our domain and that boilerplate code will give us a lot of headaches when business people will ask us to add some features to the already existing use cases.
Word. :clapping:
Loosely related to this, how would you approach this situation Jason:
We decided to use a certain design pattern, but now we realize we need to shift the approach, perhaps add a constraint we did not have before. Maybe we were not using the pattern correctly at first, or we have a new vision on our needs.
Do you try and update all the existing code right away? Do you start writing the new code under the new approach and try to update the old stuff as you go? How do you discuss this with the team and share knowledge about shifting design guidelines?
Ideally, you wouldn't have decided on a design pattern upfront. Instead, you would have deferred the decision until you felt the pain and at that point realized the appropriate design pattern.
In the real-world, I understand this isn't always possible. So, given you have chosen a design pattern and have now found it's not the right one, I would swap it out. Nothing is sacred.
If code you have written no longer fits, don't be afraid to replace it throughout the code. If it works mostly and needs adjustments, practice YAGNI and do the simplest thing that could possibly work (you mentioned adding a constraint).
YAGNI is just one principle of extreme programming. Unless accompanied by lean process it can be jarring. So definitely be sure there is a way to share these sweeping design decisions. So long as there is, they shouldn't be feared.
Feel free to get more specific. I love this stuff…
This part reminded me of something one of my sensei's (masters, teachers) use to say to us in Karate:
I tend to follow a different but related approach: I try to imagine as many future scenarios as possible, and settle on the simplest approach for the current issue that, with only a reasonable amount of changes, would allow me to satisfy those hypothetical scenarios (while not satisfying them right now).
So more briefly, keep it simple, but don't block your future self.
While I understand what you mean, you're still playing the same old game. When practicing YAGNI, you don't want to spend your time imagining every possible future scenario. You want to do what works right now. Save the time and mental energy for later.
Said another way, believe your future self is smarter. In a paradoxical way, you aren't even smart enough to block them.
I get what you're saying, but imaging myriad possible scenarios and instinctually evaluating them for being blocked, is something that in reality takes on the order of 15 minutes. TDD even is more expensive than that.
I'd like to translate the article dev.to/gonedark/practicing-yagni-3n1d into Japanese and publish on our tech blog techracho.bpsinc.jp/ for sharing it. Is it OK for you?
I make sure to indicate the link to original, title, author name in the case.
Best regards,
Absolutely.
Published the JP translation techracho.bpsinc.jp/hachi8833/2018...
Thank you very much!
I was actually surprised in a good way to see this technique mentioned in the Clean Architecture book, try to keep in mind the future but don't write code for it.
The majors impediment I think I will have when trying to apply this is with coworkers that "don't have time to refactor" and adapt the old code for new features. I hear this excuse every time I speak with a peer dev, so sometimes I take the time and try to think and code ahead 🙃
The best advice I’ve heard about YAGNI when talking to devs is to add a Y at the end. You aren’t gonna need it Yet.
Developers want to plan ahead and YAGNI on its own is a little condescending (in an I-know-better-than-you sort of way). Adding “yet” gets the point across that it may be a good idea and it may actually be needed, just not right now. Keep it in mind or write down for when it is actually required.
Oftentimes you can look back in a month or year and realize that the extra functionality wasn’t actually needed but you are prepared for the day it is needed
Very good.
Thanks!
my biggest problem with this is that I only want everyone else to do it!
When everyone on the team practice YAGNI, so much of the noise fades away. You truly get to focus on the code. It's great!