What is YAGNI?

YAGNI, You Ain’t Gonna Need It, or You Aren’t Going to Need It is a principle from Extreme Programming (and somehow related with Lean Thinking) that states that a programmer should not add functionality until it is completely necessary:

“Always implement things when you actually need them, never when you just foresee that you need them.”

Most likely, you will not need it after all or what you actually need is quite different from what you foresaw needing earlier.

Whatever the outcome, you will incur a series of costs that can be either avoided or deferred. Here’s a quick breakdown:

• Cost of building — All the effort spent on analyzing, programming, and testing a feature.
• Cost of delay — The lost opportunity to build and release another feature now.
• Cost of carry — The complexity added by the feature to the code, making the software harder to modify and debug.
• Cost of repair — The effort spent on modifying a feature because it is not exactly what you need now.

Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify. Yagni is only a viable strategy if the code is easy to change, so expending effort on refactoring isn't a violation of yagni because refactoring makes the code more malleable. Similar reasoning applies for practices like SelfTestingCode and ContinuousDelivery. These are enabling practices for evolutionary design, without them yagni turns from a beneficial practice into a curse. But if you do have a malleable code base, then yagni reinforces that flexibility. Yagni has the curious property that it is both enabled by and enables evolutionary design.

YAGNI Cost