Do the simplest thing that could possibly work

"Real progress against the real problem is maximized if we just work on what the problem really is." That framing, drawn from the Extreme Programming (XP) tradition, is the heart of this heuristic. Before adding complexity, ask yourself what is the simplest thing that could possibly work.

The rule is a counterweight to over-design. It is tempting to anticipate future requirements, generalize early, or build in flexibility for scenarios that may never arrive. Each of those choices adds code that has to be read, tested, and maintained now. Instead, implement the minimal solution that addresses the actual problem in front of you, then iterate from there.

This is an agile instinct rather than a license for sloppiness. The simplest thing that could possibly work must still work. It must still be clear, and it must still be honest about what it does. The heuristic constrains the design space, not the quality bar. Once the simplest solution is in place and proven, refactoring can shape it as understanding grows.

The heuristic is closely tied to YAGNI, which warns against building for hypothetical needs, and to the KISS principle, which favors simplicity as a design value in its own right. All three point the same way. Solve the problem you actually have, in the smallest way that genuinely works, and let the next problem reveal itself before you pay for it.