Principle of Least Astonishment
A component should behave the way its users expect it to, because every surprise is an opportunity for a mistake.
Also known as: Principle of Least Surprise, POLA, POLS, Law of Least Astonishment, Rule of Least Surprise
Category: Principles
Tags: software-design, software-development, api-design, user-experience, usability, design, principles, consistency
Explanation
Every surprise has a cost. When a system does something you didn't expect, you lose time, you lose trust, and sometimes you lose data. The Principle of Least Astonishment (POLA), also called the Principle of Least Surprise, says that a system should behave the way most of its users expect. If a feature astonishes people, change the feature.
The idea shows up in programming language and user interface design writing from the 1970s onward. Eric S. Raymond made it one of the core rules in The Art of Unix Programming.
**Where expectations come from**:
Users don't arrive empty-handed. They bring mental models from other software, from platform conventions, from physical objects and from other parts of the same system. Good design reuses those models. Bad design fights them, and the user pays for it.
**What astonishes people**:
- Similar functions with different names, argument orders or behaviors
- Hidden side effects (e.g., a getter that changes state, a `sort()` that also removes duplicates)
- Broken conventions: Ctrl+S that doesn't save, red that means success
- Destructive actions without a warning or an undo
- Defaults that do something nobody would pick
- Names that don't describe what the code actually does
**How to apply it**:
- **Follow conventions**: Reuse the patterns of the platform, the language or the domain. Getting "creative" with conventions is rarely worth it
- **Be consistent**: Things that look alike should behave alike, everywhere in the system
- **Name things honestly**: A function name should describe everything the function does, side effects included
- **Make important behavior visible**: Hidden behavior is fun to build and painful to debug
- **Know your audience**: What surprises a beginner differs from what surprises a Unix veteran. Design for the people who actually use your system
**A few examples from software**:
- Equality checks should be symmetric: if `a == b`, then `b == a`
- Command-line tools should respect common flags (`-h`, `--help`, `-v`)
- Configuration should behave the same in every environment, unless you explicitly override it
**Why it matters**:
Predictable systems are easier to learn, easier to use correctly and easier to maintain. You can reason about them without reading the source code. That's why this principle pairs so well with the Pit of Success: when the system does what you expect, the obvious action is also the right one.
Related Concepts
← Back to all concepts