YAGNI: You Ain't Gonna Need It
YAGNI is a principle of radical simplicity: don't build features now just because you *think* you'll need them later. It forces focus on current requirements, preventing wasted effort on speculative work.
The mental model
YAGNI, or "You Ain't Gonna Need It," is a principle from Extreme Programming that combats speculative development. It mandates building only what is necessary for the immediate, defined requirements, and nothing more. The cost of building something you don't need isn't just the initial development time; it's the ongoing cost of maintaining, testing, and navigating that extra complexity for the lifetime of the code.
How it works
In practice, YAGNI is a question you ask continuously: "Is this the absolute simplest thing I can do to meet the current requirements?" If you find yourself adding extra configuration options, helper functions for a use case that doesn't exist yet, or database columns "just in case," you are likely violating YAGNI. The discipline is to implement the feature as requested and stop.
When to use it
YAGNI is a cornerstone of agile methodologies. It is most effective in environments where requirements are evolving and feedback loops are short, such as when building a Minimum Viable Product (MVP). It helps teams deliver value faster by preventing "gold plating"—adding features that provide no immediate value to the user.
When not to use it
YAGNI is not an excuse for lazy or poor architectural decisions. While you shouldn't implement a complex caching layer before you have a performance problem (that's YAGNI), you should design your data access layer in a way that would allow a cache to be added later without a complete rewrite. Deferring feature implementation is smart; creating a brittle, un-extensible system is not.
One canonical example
A team is building a user profile page. A developer thinks, "Users might want to export their profile to a PDF someday. I'll add an 'Export' button and the basic logic for it now." Applying YAGNI, the team would reject this. The current requirement is only to display the profile. The export feature is not needed now, adds complexity, and may never be requested. If users ask for it later, it can be built then, based on a real need.
Interview question
A developer proposes adding a user activity log feature, arguing it might be useful for analytics in the future. According to the YAGNI principle, what is the best course of action?
- a.Implement the activity log now, but keep it disabled by default until needed
- b.Build a simplified version of the activity log now, planning to expand it when needed
- c.Design the database schema and API endpoints to easily support an activity log later, without building the log itself
- d.Postpone building the activity log until there is a clear, immediate requirement for itCorrect
Why? this is the answer
YAGNI mandates building only what is necessary for immediate, defined requirements, deferring speculative features. While designing for future extensibility (Option C) is good practice, YAGNI's direct application is to avoid implementing the feature until it's truly needed.
Just read this? Test yourself on what you have been reading.
Read the original → en.wikipedia.org
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on agile — each one lists the topics its interview covers.
See open roles