Book 09 · Software ArchitecturePage 48 of 48

YAGNI

You Aren't Gonna Need It

Pronunciation: YAG-nee

Updated September 30, 20262 min read

In short

YAGNI is a principle from extreme programming that says not to build a feature or abstraction until you actually need it, rather than because you might later.

What is YAGNI?

YAGNI, short for you aren't gonna need it, is a principle from extreme programming (XP), an agile method developed in the late 1990s. It says you should implement things only when you actually need them, not when you merely foresee that you might. Developers are often tempted to add configuration options, plugin systems, or generic abstractions for future requirements, and YAGNI argues that most of those guesses turn out to be wrong or unnecessary.

Building a feature early has several costs: the time spent on it instead of something needed now, the extra code everyone must read, test, and maintain, and the rework when the real requirement finally arrives and looks different from the guess. YAGNI works together with practices that make later change cheap, such as automated tests, refactoring, and small, frequent releases, so adding the feature when it is needed is easier than carrying it all along.

It's like packing for a beach trip: you could bring snowshoes, a tuxedo, and a tent just in case, but you'll carry the weight the whole way and almost certainly never use them. In code, YAGNI means writing the simple function that handles today's two cases instead of a framework that handles twenty imaginary ones.

YAGNI is often confused with the KISS principle. YAGNI decides whether to build something at all, while KISS is about building it in the simplest way once you do. YAGNI is also not an excuse to skip quality: tests, clear code, and refactoring are always needed, and decisions that are very expensive to change later, such as public API contracts, data formats, or security, deserve some thought up front.

Key takeaways

YAGNI stands for you aren't gonna need it.
Build features and abstractions when they are needed, not when they are imagined.
Speculative code costs time now and maintenance later, and it often guesses wrong.
It relies on tests and refactoring to keep future changes cheap.
It applies to features, not to quality practices like testing or security.

Example

Speculative design versus what is needed todaytypescript

// Speculative: plugins, options, and formats nobody has asked for yet
class ReportExporter {
  constructor(private plugins: ExportPlugin[] = [], private options: ExportOptions = {}) {}
  export(data: Row[], format: "csv" | "xml" | "pdf" | "xlsx" = "csv") { /* ... */ }
}

// YAGNI: the only current requirement is a CSV download
function exportCsv(rows: string[][]): string {
  return rows.map((row) => row.join(",")).join("\n");
}

Readers ask

What does YAGNI stand for?

YAGNI stands for you aren't gonna need it, sometimes written as you ain't gonna need it. It comes from extreme programming and warns against building features just in case.

What is the difference between YAGNI and KISS?

YAGNI is about scope: don't build something until it is needed. KISS is about design: whatever you build, keep it as simple as possible.

When should you not follow YAGNI?

Think ahead when a decision would be very expensive to reverse later, such as a public API contract, a data model that many systems share, or security and privacy requirements. YAGNI targets speculative features, not careful design of hard-to-change foundations.