Simple Design: The Simplest Thing That Could Possibly Work
Simple Design means building only what's needed now, not what you might need later. In agile projects like Extreme Programming, this keeps code lean for changing requirements.
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.
Interview question
Which approach aligns best with the Simple Design principle when faced with a potential future requirement?
- a.Create a robust, extensible architecture that anticipates and supports all foreseeable future needs.
- b.Design for maximum reusability by building generic components that can serve multiple potential purposes.
- c.Develop a basic version of the future feature, leaving it commented out until it's officially requested.
- d.Implement only the functionality currently required, adding complexity only when a new need explicitly arises.Correct
Why? this is the answer
Simple Design advocates building only what is necessary for current requirements, actively resisting the urge to add complexity for an unpredictable future. Option A, C, and D represent forms of speculative design or over-engineering, which Simple Design aims to avoid.
Just read this? Test yourself on what you have been reading.
Read the original → en.wikipedia.org
- #agile
- #xp
- #software design
- #yagni
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