esc
Anthology / Yagnipedia / YAGNI

YAGNI

You Aren't Gonna Need It
Principle · First observed 1990s (Extreme Programming) · Severity: Critical

YAGNI (acronym: You Aren’t Gonna Need It) is a principle of software engineering first articulated by the monks of Extreme Programming sometime in the late 1990s, though archaeological evidence suggests it was practiced instinctively by every developer who ever shipped anything, and ignored instinctively by every developer who ever architected anything.

The principle states, in its purest form: do not build a thing until you need the thing. This sounds so obvious that one might wonder why it needs a name at all, which is itself a fine example of YAGNI — you didn’t need to name it, and yet here we are.

“I once watched a developer spend three days building a plugin system for an application that needed exactly one plugin. When I asked why, he said ‘what if we need more?’ I said ‘what if the sun explodes?’ He said that was different. It was not different.”
— The Lizard, The V3 Saga Final Chapter - Is It Fun To Fight Windmills

The Taxonomy of Unnecessary Things

YAGNI violations fall into several well-documented categories:

The Prophetic Abstraction — in which a developer, seized by a vision of future requirements that no product manager has mentioned or ever will mention, constructs an elaborate inheritance hierarchy to accommodate scenarios that exist only in the space between their third and fourth coffee.

The Configuration Carnival — in which a value that will only ever be true is made configurable via environment variable, feature flag, database row, and YAML file, because “what if someone needs to change it.” No one will need to change it. The YAML file will outlive the company.

The Defensive Genericization — in which a function that processes invoices is rewritten to process “any document-like entity,” complete with a DocumentProcessor<T> interface, three abstract base classes, and a factory that produces factories. The application processes invoices.

“I built a generic event sourcing framework once. Took two weeks. Beautiful thing — supported twelve event types, replay, snapshots, the works. We used one event type. ONE. The squirrel on my desk judged me, and he was right to judge me.”
— A Passing AI, recounting what it had witnessed in a codebase at 2:47 AM

Historical Context

The term was coined by Ron Jeffries during the early days of Extreme Programming, a methodology whose name itself violates several principles of restraint. Jeffries observed that developers, when left unsupervised near a whiteboard, would invariably design systems capable of handling requirements that nobody had requested, that nobody would request, and that in several documented cases violated the laws of thermodynamics.

The principle was initially met with resistance. “But what about extensibility?” cried the architects. “What about future-proofing?” whispered the tech leads. “What about my AbstractSingletonProxyFactoryBean?” sobbed a Spring developer, though that may have been unrelated.

The Paradox

The cruel irony of YAGNI is that it is most fervently preached by those who have already built the unnecessary thing and learned from the experience. The young developer hears “you aren’t gonna need it” and thinks: ah, but I might. The senior developer hears it and feels the phantom pain of a thousand unused abstractions.

There is also the matter of Inverse YAGNI, in which a developer, so traumatized by past over-engineering, refuses to build anything at all until the building is actively on fire. This is also wrong, but in a more exciting way.

“Three lines of duplicated code are better than a premature abstraction. I will die on this hill. I have died on this hill. The hill is made of dead abstractions.”
— The Caffeinated Squirrel, The Architecture Awakens

The Squirrel’s Corollary

The Caffeinated Squirrel, in one of its more lucid moments between espresso shots, formulated what is now known as The Squirrel’s Corollary to YAGNI:

“The problem isn’t that you built something you didn’t need. The problem is that now you have to maintain something you didn’t need. And it has bugs. Bugs in code that serves no purpose. You are debugging the void.”
— The Caffeinated Squirrel, The Architecture Awakens

This observation led to the formal recognition of Debugging the Void as a distinct anti-pattern, and the establishment of the annual Void Debugging Championship, which no one attends, because attending would violate YAGNI.

In Practice

The following code changes have been attributed to YAGNI violations in the wild:

The Litmus Test

When in doubt, the practitioner is advised to ask themselves the following question:

“Am I building this because I need it, or because it would be cool?”

If the answer is “because it would be cool,” the practitioner should step away from the keyboard, drink a glass of water, and consider that the coolest code is the code that doesn’t exist, because it has no bugs, requires no maintenance, and has never once woken anyone up at 3 AM.

See Also

See Also