Software and engineering
YAGNI (you aren't gonna need it)
Build a capability when you actually need it, not when you foresee needing it; the forecast is usually wrong and carrying the code is not free.
Extreme Programming (XP): the phrase is from Kent Beck and Chet Hendrickson on the Chrysler C3 project; written up by Ron Jeffries in April 1998 and by Martin Fowler in May 2015.
Jeffries's wording of the practice: always implement things when you actually need them, never when you just foresee that you need them. 'You aren't gonna need it' (YAGNI) is the reply to 'we will need this later'. Fowler's 2015 essay turns it into an accounting. A presumptive feature has a cost of build (the analysis, code and tests), a cost of delay (the feature you did not ship instead), a cost of carry (complexity that slows every later change while the feature waits) and a cost of repair (if it is finally needed, it was built against an understanding that is now months stale). Since forecasts of need are poor, the bet has negative expected value most of the time.
It holds because software that is kept easy to change makes the option to build later worth more than building now. Fowler is explicit about the boundary: YAGNI applies to capabilities built to support a presumptive feature, not to effort that makes the software easier to modify. Refactoring, tests and continuous delivery are what make deferral safe, so they are not violations. Jeffries's own example is the smallest one: write the getter you need now, not the setter and the other getters you can imagine. In practice the discipline shows up as deleting the config flag, the abstract base class and the second provider adapter until a second real case exists.
The rule fails where retrofitting is expensive, and that is a property of the thing, not of the forecast. Security, the data model, internationalisation, time zones, multi-tenancy and audit trails are all cheap to include at the start and migrations later. The two-digit year is the famous case: a narrow field that cost an estimated $100 billion in the United States to widen. The right question before deferring is not 'will we need it' but 'what does it cost to add later'. When the answer is a day, defer; when it is a migration across every table or every record ever written, it is a one-way door and belongs in the design now.
Example
Programs written over several decades stored the year in two digits and assumed the century, a choice that was cheap at the time and invisible until the dates ran out. In November 1999 the US Commerce Department's Economics and Statistics Administration estimated that American businesses and government would spend more than $100 billion between 1995 and 2001 finding and fixing those date fields, about $365 per citizen, with the federal government's share around $8 billion; an Office of Management and Budget report in February 1997 had already put the federal agencies' estimate at $2.3 billion for fiscal years 1996 to 2000. The narrow field was the data model, the one part of a system that cannot be added later for the price of adding it now.
Where it applies
Delete the speculative flag, the pluggable backend and the generic framework until a second real case appears. Before deferring, price the retrofit: a second large language model (LLM) provider is a day's work, but a tenant column across every table, a missing audit log, or the version of the embedding model that produced each stored vector is a migration, so decide those up front.
Think about it
What are you building this week for a requirement nobody has asked for yet, and what would it cost to add it when they do?
Applied it to something real? Log it.
Test yourselfFowler lists four costs of building a presumptive feature now. Name them, and say which one is paid even if the feature is never needed and the code is never touched again.
Build, delay, carry and repair. Carry: the added complexity slows every other change for as long as the code exists, whether or not the feature is ever used.
Related models
- Gall's lawA complex system that works grew from a simple system that worked; one designed complex from the start rarely works and cannot be patched into working.
- Premature optimisationDo not tune code for speed before you have measured where the time goes; most of it is in a few places, and you will guess them wrong.
- One-way and two-way doorsMake reversible decisions quickly and save slow, careful deliberation for the ones you cannot undo.
- OptionalityPrefer positions that give you the right, but not the duty, to act later, so you can take the upside when it appears and walk away when it does not.
- Via negativaImprove things by removing what does harm before adding anything new, because we usually know more about what is wrong than about what is right.