Principle of Least Astonishment

Systems should behave in a way that is least surprising to the user. This idea is the overarching theme of many of my thoughts on product development. It shows up again and again in different places. 

• Be consistent. Convention in Consistency is an accounting term, but there’s an analogy in software development. Inconsistency is unexpected.

• Favor idempotency. Ensure the same operations can be performed multiple times without unintended side effects. We’re naturally surprised when doing the same thing twice has different results. 

• Have Sensible Defaults. The least astonishing configuration is no configuration at all. 

• No unnecessary details. (Chekhov’s Gun of Product Development). Additional context confuses users. (And LLMs). 

• Change only one thing at a time. Users can reason about changes much easier when only one thing changes at a time.

• Change only one thing at a time, in the correct order.  (Wrong sequences for startups). A series of unrelated changes can leave the system in a confusing state for users. 

• Program to the interface. Developers understand common interfaces. And there’s plenty of tooling for them.

• Solve the simple case. The simple case is also the least astonishing to the user. 

• Maintain backward compatibility. The way it’s always worked is how users expect it to work.