alt Hacker News> 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
I could do this simplistic thing now but in 3 weeks that will be insufficient so since we’re going to need this more complicated thing I want to do it now.
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.
> The first paragraph set the context
The first paragraph is exactly what I've observed that make me think YAGNI is a bad practice.
3 weeks is very short, it's basically next Sprint. This stupid developer is, without flinching, saying, "we may (or may not) already know that what we are building during this sprint will not be suitable to next sprint, but let's build it anyway because YAGNI".
How is that not stupid? Just clarify. Just say "oh? ok, maybe it is a good idea, let's have a look". Don't interrupt with "YAGNI" like it is done in the article. And don't pretend that this is smarter than doing exactly the equivalent stupid thing of jumping into over-engineering without checking.
It is really crazy to me that people don't read the beginning of this article and don't scream "WTF, why is this dev so stupid".
Don't get me wrong, maybe Chet is an idiot and came up with a over-designed solution. The problem is that YAGNI does not care: YAGNI applies both if Chet is an idiot or if Chet is a stakeholder that know better than the dev what the direction should be.
You are saying "you don’t have the full specification", but you have no idea if you have the full specification or not. The whole text is totally compatible with a situation where you exactly have the full specification, where the devs are being explained what is coming soon, and that one dev is just plugging his ears: "nanana, YAGNI, I don't want to hear what comes next".
That's exactly my problem with YAGNI: when you read this article, you should hear alarm bells. The fact that the author just chooses to not even try to check if Chet is correct or not should be a red flag. But because you have drunk the cool-aid of YAGNI, you don't even notice that the correct solution for the dev was not to flatly block the discussion with "you ain't gonna need it", but "yeah, let's discuss this, are you really really sure we will need it, are you sure it's not over-engineered. If not, great, let's do like that."
> 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.
Again, I have been in these situations, and I have seen, with my own eyes, that what you say is incorrect.
I have acted as a developer, as a architect, as a stakeholder, and as an observer seeing devs and stakeholders trying to work together.
What I've observe is more nuanced than that:
- if a dev comes up with some abstraction, there is indeed some chance this is a waste of time and this abstraction is not needed
- if a non-dev pushes for some abstraction or structure, there is some chance that it is a waste of time, but also a lot of chance that it is not, and this is not negligible at all and in fact crucial for doing a good work.
- if a dev says YAGNI, there is close to 90-100% chance that they have no understanding of what is the big picture, which is a problem anyway. If they had some understanding of what is the big picture, they will not say YAGNI, they will say "oh? are you sure? it is not compatible with my understanding, but maybe I'm wrong, let's clarify".
- these devs are very very unaware of how inefficient they are. They deliver things that does not correspond to what the stakeholders wanted, but then don't have a relationship close enough with the users for them to notice that it's suboptimal, or blame it on the stakeholders or on the timeframe or on other things.
> 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.
But isn't that exactly the point? In this article, you and the author have no idea if the design you propose to do right now is compatible with what is needed. In this article, the author shut down the question of "let's think about what is needed", they just said "someone decomposed this piece of work into few steps, so I will do each piece blindly without looking at the big picture, because otherwise it is not YAGNI".
> IMO, there’s no argument that can stand against “This is not part of the current requirements”
You should always assume that requirements are wrong. If someone is coming to you saying "hey, I think I've understood that what is needed is ...", you should never answer then "shut up, we do the requirements blindly". If there are doubt, just clarify instead of putting your head in the sand with YAGNI.
The reason the requirements should be assumed as wrong is not because the person who came up with the requirements is incompetent, but it is because requirements are impossible to come up with correctly. Because they require the person who come up with the requirements to already know exactly all the subtleties in all areas of expertise. Imagine that person is a non-dev. They have a good understanding of what they want. But how can they know that within ThingyDB, what people call an integer is in fact what normal people will call a fraction. So they say "we want an integer", and the devs deliver something that return a fraction. And if the non-dev says "it's not what I had in mind", then the devs will say "well your requirements were bad". Both it cuts both way: it is also not the devs fault if in their context, "integer" means that specific object. Both interlocutors don't know what they don't know. They cannot write requirements where every single word is over-defined just in case.
(And if you have the opportunity, ask a dev team to come up with requirement outside of their subject of expertise, it is usually hilarious. But also a really good eye-opening exercise for these devs who were condescending towards the non-devs)
This is an obvious case to illustrate, but this is very close to what happen in practice. An example I have in mind is between the Project team, where they collaborated with "organisation", which are just other partner companies, and the Dev team, where they had "organisation_id" used for authentication. And of course, no one noticed that the same company would have several organisation_id because they had different project and different contact person. The devs were convinced that several entities that were in fact the same organisation (according to the common sense definition) were, according to them, several different organisations.