the principle of least astonishment
expressionprogrammingweb dev
A component should behave the way most users will expect it to behave; surprise is a defect.
The principle, circulating since the 1970s, judges designs by the gap between what they do and what a reasonable user predicts: an interface that astonishes will be misused, however well documented. It governs API design, defaults, error handling, and UI alike. When two implementations are equally correct, ship the one that needs no explanation.
A system should behave the way its users expect, and where that is impossible it should at least be surprising in the least damaging way. The principle sounds soft until you notice that most usability failures and a good number of security incidents are astonishment: someone reasoned correctly from a wrong model.
It applies most sharply to the interfaces engineers build for each other. A function named get that also writes, a flag whose meaning inverts in one code path, a command that is destructive without asking: each is defensible in isolation and each violates the expectation someone brings from everything else they have used. Consistency with convention usually beats local cleverness, because the reader's model comes from elsewhere.
The security dimension deserves its own note. Astonishment is where dangerous mistakes live: a delete that does not confirm, a default that shares more than expected, an option whose name suggests the opposite of what it does. When the safe path and the expected path diverge, users end up on the expected one, so making the expected behaviour the safe behaviour is worth more than any amount of documentation explaining the difference.
Also known as: POLA, least surprise