2 min read
Every application has an inherent amount of irreducible complexity that can only be shifted, not eliminated.
Takeaways
- Good design often requires that developers absorb most of the complexity (through smart defaults, algorithms, etc.) so that the user’s interaction is simpler.
- If your UI requires the user to manage many settings or steps, you’ve conserved complexity in the wrong place (on the user side). Often, it’s better to design the product to manage that complexity internally.
- Good design often hides complexity without eliminating it by handling it internally.
Overview
Tesler’s Law, also known as the Law of Conservation of Complexity, states that for any system, there is a certain amount of complexity that cannot be removed; it’s inherent to the problem. The key is who deals with it.
If you design software that’s very simple for the user, it likely means the software is doing a lot of complex work under the hood. If you make the software very simple internally, it might dump complexity on the user (e.g., requiring many manual steps).
Tesler’s Law encourages designers to move complexity away from the user experience whenever possible.
Tesler’s Law
Examples
A classic example is scheduling meetings, which is inherently complex (finding a common time). A tool like Calendly hides that complexity from the user (the software handles it), whereas an email chain to schedule a meeting places that complexity on the user to figure out.
In system architecture, imagine designing a database vs. putting logic in application code. Sometimes pushing logic into the DB (such as stored procedures) can simplify app code but add complexity to the DB layer, or vice versa. Complexity isn’t gone, just relocated.
In the end, the law reminds us that no design is without complexity. It’s all about smartly allocating complexity to the right place.
Origins
Larry Tesler, who worked on Apple Lisa and early GUI concepts, formulated this principle in the 1980s. He observed that you can’t make everything simple without someone handling complexity. It’s a fundamental trade-off in design.
Further Reading
Why Life Can't Be Simpler Farnam Street on the conservation of complexity
Law of Conservation of Complexity Deep dive into Tesler's Law and its implications
Simplicity is Overrated Why chasing simplicity isn't always the answer
Law of Conservation of Complexity (Wikipedia) Wikipedia article on Tesler's Law
Want to go deeper?
All 63+ laws are covered with more depth, examples, and practical guidance in the Laws of Software Engineering book.
Last updated: June 24, 2026

Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.