Simple Design: The Simplest Thing That Could Possibly Work

THE MENTAL MODEL: Simple Design, a core practice of Extreme Programming (XP), is a discipline to build only what is necessary to meet today's requirements. It's not about being naive or lazy; it's about actively resisting the urge to add complexity for a future you can't predict. This principle is often summarized as doing "the simplest thing that could possibly work."

HOW IT WORKS: A design is considered 'simple' if it meets four criteria, in order of importance. First, it passes all automated tests, ensuring correctness. Second, it reveals its intention, meaning the code is clear, expressive, and easy to understand. Third, it has no duplication (following the Don't Repeat Yourself or DRY principle). Fourth, it contains the fewest possible elements, like classes and methods. This hierarchy guides refactoring: you make it work, then you make it clear, then you remove duplication.

WHEN TO USE IT: Use Simple Design in agile environments where requirements are expected to evolve. By avoiding investment in speculative features, teams can respond to change more quickly and cheaply. It maximizes the amount of work not done, keeping the codebase lean, focused, and easier for new developers to understand. This is especially powerful for startups and projects in a discovery phase.

WHEN NOT TO USE IT: The approach should be applied with caution in domains with extremely stable, complex, and high-stakes upfront requirements, such as in aerospace or medical device software. In these cases, significant upfront design and formal verification may be legally or practically mandated. However, even in these contexts, the principles of clarity and avoiding unnecessary complexity remain valuable.

ONE CANONICAL EXAMPLE: Imagine a request to export user data as a CSV file. A complex, forward-looking design might involve creating an abstract ExporterFactory and multiple concrete classes for CSVExporter, JSONExporter, and PDFExporter to handle future requests. The Simple Design approach is to write a single, well-tested function that just generates the CSV. If, and only if, a future requirement for JSON export arrives, you would then refactor the code to introduce the necessary abstraction.