Pit of Success
Build systems so that the easiest path is also the right one: people fall into good results by default, and they have to work hard to get things wrong.
Also known as: Falling Into the Pit of Success, The Pit of Success, Make the Right Thing Easy
Category: Principles
Tags: software-design, software-development, api-design, design, user-experience, developer-experience, principles, defaults, error-prevention
Explanation
Most systems make you climb toward success. You need to know the rules, read the docs and stay careful the whole time. One slip, and you slide back down. The Pit of Success flips that picture. Success sits at the bottom of a pit, and you simply fall into it.
Rico Mariani coined the term while working on the .NET platform at Microsoft. His goal: "we want our customers to simply fall into winning practices by using our platform and frameworks." Brad Abrams and Jeff Atwood (Coding Horror) spread the idea later on. The opposite also has a name: the "Pit of Despair", where the obvious path leads straight to bugs, security holes or slow code.
**Why does this matter?**
Because people don't read the manual. They copy the first example they find, keep the defaults and move on. If your system only works when people are careful, it will fail. Not once in a while. REGULARLY. The rules everyone "knows" are usually the first ones to get broken.
**How it works**:
- **Defaults do most of the work**: Most people never change a default (see the default effect). So the default must be the safe, correct and fast option
- **The obvious way is the right way**: The first API, button or command someone reaches for should give a good result
- **Wrong things take effort**: Dangerous operations need an explicit, deliberate opt-in (e.g., a `--force` flag, an `unsafe` block)
- **Mistakes are loud and early**: When misuse is possible, the system fails fast and tells you why
- **Design for the person in a hurry**: Assume they skimmed the docs (if they opened them at all)
**Examples**:
- Template engines that escape HTML by default. You have to opt out to create an XSS hole
- Database libraries that use parameterized queries by default, which blocks most SQL injection
- Rust's ownership model: memory-safe code is the default, and `unsafe` code is explicit and easy to search for
- Type systems that make invalid states impossible to write (see Make Illegal States Unrepresentable)
- Project templates (i.e., golden paths) that ship with tests, linting and CI already set up
- Physical design: plugs that only fit one way, doors that show you whether to push or pull
**How to apply it**:
1. List the mistakes people make most often with your system
2. Ask yourself how the design invites each one
3. Change the defaults, the interface or the constraints so the mistake stops being the easy path
4. Make correct usage the shortest and most convenient option
5. Keep friction for dangerous or irreversible actions, and only there
**Beyond software**:
This works for your personal systems too. Put the fruit at eye level and the snacks at the back of the cupboard. Leave your phone in another room while you write. Create templates for the work you repeat every week. Each one is a small pit of success: the good behavior happens because it's the easiest option around.
Keep in mind that willpower runs out. A well-designed environment keeps working when you're tired.
Related Concepts
← Back to all concepts