alt Hacker NewsLook at the article itself:
> Chet said, “You don’t understand. We’re definitely going to need it. See, here’s an example…”
> Me (interrupting), “You aren’t going to need it.”
> Chet, get frustrated, “But we really are…”
> Me, “You aren’t going to need it.”
This is a clear example of YAGNI being used when the dev, actively, does not care if the other person has any argument to defend it will be needed.
YAGNI itself is badly designed, it gives the wrong answer. It should be "Build Thing Carefully": no abstraction if no argument, abstraction if no good argument beyond "YAaGnNIii".
And I know devs would just say "but devs who don't listen is super rare", but it is not true: you probably read the article and did not flinch, not noticing that it's a clear situation where the dev actively refuse to listen to the arguments. How many time did you witness or participate to such situation and still think it never happens?
At the end, I don't understand: just do "Build Thing Carefully", where what you built is well-thought, and not only you get YAGNI for free, but you also avoid the problem with refusing to build something that is needed.
> This is a clear example of YAGNI being used when the dev, actively, does not care if the other person has any argument to defend it will be needed
The first paragraph set the context
You can solve today’s problem and do some groundwork to extend later. What you don’t do is solving today’s problem with a solution for a future problem.Whatever complicated thing that may be wanted, meaning you don’t have the full specification, as it’s not a current problem for a stakeholder.
In systems design, you’re solving problems belonging to the stakeholder, the project resources, and engineering needs and constraints. Going outside the union of those sets is overengineer, building things no one needs, costing resources that should be allocated to other things, and complicating the design because other things need to react to that new feature.
> YAGNI itself is badly designed, it gives the wrong answer. It should be "Build Thing Carefully": no abstraction if no argument, abstraction if no good argument beyond "YAaGnNIii".
YAGNI is not a case again against abstraction. It’s a case against features. You can always design code to modularize and decouple an implementation from where it’s used. What you don’t do is creating extra code for things that are not needed yet.
Why? Because anything that is going to be needed between now and that X moment in the future will have to take your design into account. The cost may be negligible, but often it’s not.
IMO, there’s no argument that can stand against “This is not part of the current requirements”. Solving future requirements ahead of time is a fool’s errand. But you can always make the current design flexible enough for future changes.