What is the YAGNI principle?
YAGNI - You Aren't Gonna Need It
YAGNI means I should not implement functionality, abstractions or extension points until there is a real requirement for them. It helps prevent speculative complexity and keeps designs focused on current business needs. As a senior engineer, I balance YAGNI with architectural foresight: I do not build hypothetical features, but I still preserve sensible boundaries where the current requirements already justify them.
- 1
Implement real requirements rather than speculative features.
- 2
Avoid unnecessary abstractions and extension points.
- 3
Reduces code, testing and maintenance cost.
- 4
YAGNI does not mean ignoring known architectural requirements.
- 5
Combine YAGNI with good boundaries so future change remains possible without building the future prematurely.
Scenario Questions
0-2 years experience
- 1You're adding a new method to a class to support a feature that might be added next quarter. How would you decide whether to implement it now?
- 2A teammate suggests creating a generic utility class for a one‑off calculation. What would you ask before writing it?
- 3During a code review you see a stubbed‑out feature flag for a future feature. What would you do with it?
2-5 years experience
- 1Your team is building a payment module and you notice a helper class being built for future reporting features. How would you evaluate if that's appropriate?
- 2A bug appears after you added extra validation that wasn't required for the current use case. Walk me through how YAGNI relates to that.
- 3When estimating effort, how do you balance YAGNI against potential future requirements?
5-8 years experience
- 1In a microservice architecture, a service team proposes adding a generic event bus to handle future events. How would you assess this decision using YAGNI?
- 2Your legacy codebase has many layers of abstraction that were added preemptively. How would you approach refactoring them while respecting YAGNI?
- 3During a performance incident, you discover that an over‑engineered caching layer is causing latency. Explain how YAGNI could have prevented this.
8+ years experience
- 1Your organization is planning a platform migration and wants to build a highly extensible framework now. How would you argue for or against a YAGNI approach at this scale?
- 2Cross‑team, there's a proposal to standardize a DSL for future use cases that aren't defined yet. How would you evaluate this from a YAGNI perspective?
- 3When setting long‑term engineering standards, how do you incorporate YAGNI to avoid technical debt across multiple product lines?
Follow-up Questions
- Can you give an example where following YAGNI saved you time or effort?
- What signals tell you it's safe to defer a feature?
- How do you convince stakeholders who push for future‑proofing?