You’ve been sold a lie. Every time you open a beautifully simple app, you’re looking at a carefully constructed facade. Behind that smooth UI is a screaming mess of duct tape, technical debt, and engineers who haven’t slept in days. The app feels effortless. The backend is a nightmare. And that’s exactly how it’s supposed to work.
This isn’t a bug. It’s the Law of Conservation of Complexity, first articulated by Larry Tesler—the guy who literally gave us copy-paste. Tesler said: “Every time you make a product simpler for the user, you make it more complex for the engineer. That’s not a bug — it’s the law.”
Think about it. When you swipe left to delete an email, you don’t see the distributed database shards, the conflict resolution logic, or the 47 retry mechanisms. The user sees magic. The engineer sees a house of cards. Complexity didn’t disappear. It was just relocated.
Most product managers ignore this. They think they can break the law. “Can’t we just make it simpler?” I once had a PM ask me that. I wanted to scream. Simplicity is not a feature. It’s a debt transfer. Every time you ship a “delightful” experience, you’re taking out a loan on the engineering side. One day, that loan comes due.
Remember when Apple removed the headphone jack? They shipped the complexity to Bluetooth dongles, battery anxiety, and a thousand lost adapters. The phone got simpler. The user’s life got… not simpler. The system just found a new place to hide its mess.
Here’s the truth: You cannot destroy complexity. You can only decide who gets to carry it. The best engineers aren’t those who eliminate complexity. They’re the ones who strategically allocate it—pushing it to the part of the system that can absorb it without breaking, or to the user who can handle it.
So stop trying to build a zero-complexity product. It doesn’t exist. Instead, ask: “Where does this complexity hurt the least?” If you force it onto the user, they’ll churn. If you force it onto the backend, you’ll drown in technical debt. And if you pretend it doesn’t exist, you’ll wake up one day with a system that no one can fix.
That’s the ugly truth. Simplicity is an illusion. Wealthy companies just get better at hiding the mess. The rest of us have to own it openly.
So own it. Stop chasing simplicity. Start deciding where the pain lives.
FAQ
Q: Isn't Tesler's Law just an excuse for bad engineering?
A: No. It's a recognition of trade-offs. Bad engineering tries to hide complexity with no plan for the consequences. Good engineering acknowledges the complexity lives somewhere and designs around it. The law doesn't excuse sloppiness—it demands intentionality.
Q: How do I apply this law in my own product?
A: Stop trying to make everything 'simple.' Instead, map every feature's complexity: does it land on the user (cognitive load, extra steps) or on the system (data sync, edge cases, maintenance)? Then decide which is more tolerable. Sometimes the right answer is a janky UI that saves three months of backend work.
Q: What about Feynman's quote: 'If you can't make it simple, you don't understand it yet'?
A: Feynman was talking about understanding, not building. You can fully understand a system and still be unable to make it simple for a user because the underlying problem is inherently complex. Tesler's Law is the reality check: no amount of understanding can eliminate the fundamental complexity of a system—it only lets you hide it better.