In other words, "You May Not NeedYAGNI".
YAGNI (You Ain't Gonna Need It) is a well intentioned summation, transformed into a subjective expression of superiority in practice.
You May Not Need It (YMNNI, pronounced "yum-nee") should be preferred most of the time.
First, some history.
The amount of times I've heard or seen "per YAGNI, get rid of this" (subjectively) misapplied is uncountable, and I haven't been in industry that long.
So what is the original intent? Per the linked page, YAGNI is:
a principle which arose from extreme programming (XP) that states a programmer should not add functionality until deemed necessary.
The problem with YAGNI is usually in the way it is deployed. It is deployed as a totality, in most instances. The YAGNI purveyor whom decides to pull Occam's Razor and slit the throat of the work at hand like Sweeney Todd, does so with absolution and often little justification. Raise your hands if in code review you've gotten the comment:
YAGNI, remove.
✋✋✋
Sometimes it is management which doth pull the razor, sometimes colleagues, most times it misses the mark.
What is left over after a YAGNI claim is usually frustration and angst. In my early years, I would take a YAGNI claim on go on the defence. However, after a lot of hard work, intentional learning, and some brutal self-reflection, I've come to approach YAGNI claims void of any explanation (and which have an associated explanation) with questions for the purveyor. YAGNI is more of a ideological mandate in pratice.
Some quite succinct ones are: "How so?", "I don't understand the perspective here. Will you please expand?."
However, there seems to me to be a better alternative. Mentioned above is the phrase You May Not Need It (YMNNI).
Why is this preferable, in my mind? Because it leads to shared exploration and understanding of what is being criticized. Theoretically, the result is shared ownership of the result.
You May Not Need It is a signal that:
- I recognize something is created and may be serving a grander purpose which isn't immediately obvious to me.
- I am not claiming to have a special insight.
- I want to understand this at a better depth, let's discuss in the context of 1 and 2.
There are cases where it is appropriate to YAGNI, I'm not advocating for getting rid of it. What I am advocating for is a similary succint buzzword/phrase which is a means to approach:
- Signaling something isn't clicking on my end.
- Opening the door to collaborating rather than mandating it must be so.
- (Hopefully) Encouraging exploration.
Post Script
The above isn't specific on code, systems, or the like. The reason being is I've had instances where the following have been decried as YAGNI: code, design, tooling. Some of it was, some of it wasn't. The problem is at the end of the day a people problem. Engineers, either trained via university, the school of hard knocks, or both, tend to want to be right because of a perceived boost in technical status. YAGNI can be, and is, deployed as a means to boost one's status while failing to facilitate the most imporant aspect of any valuable system: collaboration and shared ownership.
If you're going to deploy YAGNI, it needs to have at least an attempt on an objective rationale. I'd take the following any day:
I don't understand the intent with X. It seems to be unnecessary. Will you please provide me with the context as to how X was constructed?
or to use a succinct YMNNI:
YMNNI, but I don't have all the context. Mind having a quick huddle to explore X?
or even to use YAGNI:
It seems to me like X may be YAGNI. Let's sync up on the details of X before moving forward, as I may be missing the context/intent here.
At the end of the day, your mental model isn't perfect, your teammates mental model's aren't perfect, neither are your managers or your skip managers. There is something different to be brought to the table for each contributor which can (and should) lead to an aligned outcome.