Do the simplest thing that could possibly work
Developers waste time building for imaginary futures—80% of value comes from 20% of the work, and you're terrible at predicting what you'll actually need anyway.
Read Original Summary used for search
TLDR
• The "we're going to need this someday" mindset is a distraction that compounds errors—when you're thinking about tomorrow, you're not solving today's problem
• Studies show developers are bad at predicting future needs; the best case of building ahead is breaking even, any bad luck puts you behind
• If code is too complex to modify later, it's just too complex—simplify it so adding capabilities is easy, don't make it more complex by adding them now
• Software follows 80/20: 80% of benefit comes from 20% of work—find that simplest 20% and do it
In Detail
The core discipline of XP development is doing the simplest thing that could possibly work—not the most stupid thing, but ruthlessly simple. Developers have years of training in building "general solutions," but real progress comes from working on what the problem actually is, not what it might become. The article emphasizes this is a constant battle: "we have to remind ourselves of this rule continually."
The argument against building for the future is mathematical and psychological. Best case, you break even by building ahead. Any bad luck and you fall behind. Meanwhile, thinking about "someday" distracts you from today's goal. Studies show developers are poor at predicting future needs anyway. The 80/20 rule applies: 80% of value comes from 20% of the work—find that simplest 20% and execute it. The common objection is "but I'm immersed in this object now, it'll be harder later"—but if the object is so complex that future modification is hard, it's just too complex. Simplify it so adding capabilities is easy, but don't add them preemptively.
The practical implication is treating this as a discipline problem. In well-designed systems (the article uses Smalltalk as an example), code is easy to modify, so there's no technical reason to build ahead. Your mission is fastest progress against the real problem, not the hypothetical one. Add comments describing key ideas, keep things simple enough that future you can easily extend them, and leave the future to the future.