Principle: You Ain't Gonna Need It (YAGNI)

Developers build features and abstractions for anticipated future needs that never materialize, adding complexity without value.

YAGNI in practice:

What YAGNI means:

• Don't build features until they're actually needed
• Don't add abstractions until you have multiple concrete cases
• Don't design for hypothetical future requirements

What YAGNI does NOT mean:

• Don't think about architecture at all
• Write spaghetti code
• Ignore well-known patterns that fit
• Skip making code testable

Examples:

YAGNI violation: Building a plugin system for an app that will
only ever have one implementation.

YAGNI violation: Adding an admin panel 'because we might need it'
when no one has asked for one.

YAGNI violation: Creating an ORM wrapper 'in case we switch
databases' when there's no plan to switch.

NOT a YAGNI violation: Using dependency injection (makes testing
possible now).

NOT a YAGNI violation: Input validation (security is always needed).

The cost of YAGNI violations:

• Code that must be maintained but provides no value
• Abstractions that make the code harder to understand
• Wrong abstractions that don't fit when the real need arrives

The rule: Build the simplest thing that solves today's problem. When tomorrow's problem arrives, you'll understand it better than you do today.

Martin Fowler / XP principle. Studies show that anticipated requirements are wrong roughly half the time. Building for them costs time now and creates maintenance burden forever.

Software architecture and design decisions