YAGNI — You Aren't Gonna Need It — is a principle from Extreme Programming, closely associated with the same Pragmatic Programmer and agile-adjacent tradition discussed elsewhere on this shelf, that advises against building functionality or flexibility for a future need that isn't actually present yet, even when that future need seems likely or even highly probable. The principle is frequently misread as an argument against planning or foresight in general, which isn't quite what it claims — it's a more specific argument about where the cost of a wrong guess about the future actually lands. A concise external explanation can be found in Martin Fowler's YAGNI note.

The asymmetry the principle is built on

The case for YAGNI rests on a specific asymmetry: building speculative flexibility for a need that turns out to be wrong has a real, paid-upfront cost (the extra code, the extra abstraction, the extra complexity, discussed in the Philosophy of Software Design guide on this shelf) whether or not the anticipated need ever materializes, while building only what's needed now and adding flexibility later, once the actual need is concretely known, defers that cost to a point where it can be paid with much better information about what's actually required. Software, unlike some other engineering disciplines the analogy is sometimes borrowed from, is usually cheaper to extend later than physical infrastructure is — which is part of why deferring a decision until it's actually necessary is often genuinely viable in software in a way it might not be elsewhere. The habit of improving a system before a crisis is also discussed in this page.

This means the real comparison YAGNI asks you to make isn't “build it now versus never build it” — it's “build it now, based on a guess, versus build it later, based on an actual, concrete requirement.” Framed that way, the case for waiting is considerably stronger than the more casual misreading of the principle (“don't think ahead”) suggests.

Where YAGNI gets misapplied as an excuse

The principle is sometimes invoked to justify avoiding any design consideration for extensibility at all, including cases where a small amount of foresight would cost very little and would meaningfully reduce future pain — which is a different, less defensible claim than the principle actually makes. YAGNI is specifically about not building unused functionality or unused flexibility, not about refusing to write code in a way that would be reasonably easy to extend later if the underlying design is otherwise sound. A well-factored, cohesive module (discussed in the coupling and cohesion guide on this shelf) tends to be easy to extend later regardless of whether it was explicitly built with extension in mind — which is often a better investment than either speculative flexibility or willful disregard for future needs.

Why this connects to the rest of this shelf

YAGNI is, underneath, another specific application of the complexity-management framing from A Philosophy of Software Design, discussed elsewhere on this shelf: speculative flexibility is a form of complexity, paid upfront, in exchange for a benefit (accommodating a future need) that may never materialize. Evaluated by its net effect on complexity rather than by whether it follows a specific rule, unused speculative flexibility often fails the same test that unnecessary abstraction does — a real, ongoing cost, for a benefit that hasn't yet, and may never, arrive.

YAGNI isn't an argument against thinking ahead. It's an argument that the cost of guessing wrong about the future is usually lower if you pay it later, with better information, than if you pay it now, speculatively, for a need that might not materialize the way you expect.

Applied with that understanding, YAGNI sits comfortably alongside rather than in conflict with good design practice — it's not permission to design carelessly, it's a specific argument for deferring a particular kind of cost until there's real evidence it's worth paying.