· Systems · 7 min read
Tesler's Law: Complexity's Enduring Burden
Larry Tesler gave us cut, copy, and paste. He also gave us an uncomfortable truth: complexity never disappears. It just moves. The only question is who gets stuck with it.

Tesler’s Law: Why Your Software is a Beautiful, Hidden Nightmare (and Who Should Pay for It)
Let’s start with a brief, highly necessary history lesson—mostly because it involves literal scissors and glue, which is a comforting thought when your current Javascript framework is collapsing under its own weight.
Back in the mid-1980s, a man named Larry Tesler was working at Xerox PARC. He spent a significant chunk of his time trying to convince management that they should actually invest time (and, god forbid, money) into building a simple, unified application design framework. His goal? To make software development faster and, crucially, less painful for the poor souls using it.
If you’ve ever used cut, copy, and paste, or even looked at a digital clipboard, you can thank Larry. He developed these features alongside Tim Mott while working on the Gypsy word processor between 1973 and 1976.
And no, the names weren’t a product of some abstract high-concept brainstorming session. Larry literally took them from the physical publishing offices of the time, where editors would physically slice up galleys of paper with scissors and glue them onto layouts. Revolutionary? Yes. A literal translation of analog misery into digital comfort? Also yes.
Later, Larry took his talents to Apple Computer, where he helped design the Mac’s object-oriented software framework. It was during this tenure, around 1984, that he formulated his famous law:
Every application has an inherent amount of irreducible complexity. The only question is: Who will have to deal with it.
Of course, that sounds very elegant and textbook-ready. But Larry was a pragmatist who actually had to deal with real-world users (and lazy developers). To bridge the gap between theory and the daily grind of software development, he put his philosophy much more bluntly in an interview:
Engineers should spend an extra week trying to reduce complexity at the user end, rather than having millions of users spend an extra minute each day due to unnecessary complexity. Doing so makes it easier for engineers but punishes users in return.
But let’s pause and think about what this law actually means. Because underneath the user-friendly veneer of modern tech lies a terrifying abyss.
Complexity is Given (And It’s a Nightmare)
The world around us is shockingly complex, and what happens inside our computers is, frankly, an absolute disaster. Almost every operation we perform looks simple from the outside, but under the hood, it’s a miracle it works at all.
Take opening a web page. You click a link. Easy, right?
Wrong. Your browser is working overtime. In fact, in Fuckup Almanac vol 2, I put forward a thesis that your web browser is potentially the most complex application running on your computer. It’s juggling DNS lookups, compression, real-time encryption, and parsing at least three different programming languages on the fly: HTML, CSS, and JS.
(A brief, highly self-indulgent sidebar: if you had told me a decade ago that HTML and CSS were “programming languages,” I would have prepared a very long, very loud lecture for you. But with the advent of CSS3, the HTML+CSS combination became officially Turing Complete. I am absolutely not going to explain what that means right now—look it up. The point is, after years of evolution, these markup languages graduated into the big leagues of actual programming. Ninety-nine percent of the population couldn’t care less, but my inner nerd insisted on taking the mic for a moment.)
Or how about sending an email? Oh boy. The sheer amount of digital gymnastics that occurs the second you fill out the To, Cc, and Subject fields and hit “Send” is enough to make any sane systems administrator weep.
Even the “stupid” act of dragging a file from one window to another triggers a massive inter-process communication dance. Pipes are opened, security tokens are validated, and the operating system has to suddenly coordinate local file systems, physical storage controllers, or worse, latency-ridden network drives.
The complexity doesn’t disappear. You can’t delete it. You can only hide it. And the only reason you aren’t screaming at your monitor right now is because someone, somewhere, invested a massive amount of energy into designing the right abstraction layer.
This Goes Far Beyond IT
While Tesler formulated this law for software engineering, it applies to pretty much everything in human existence.
Let’s look at your car. You get in, press a button (or turn a key, if you’re feeling vintage), and the engine goes vroom. You put it in gear, press a pedal, and off you go.
But beneath that plastic dashboard is pure engineering witchcraft. Before that button even responds, an immobilizer system has to perform a cryptographic handshake with your key fob. Once cleared, your engine initiates literally thousands of controlled explosions per minute to generate kinetic energy. That energy is managed by a transmission (and don’t even get me started on modern automatic gearboxes) to spin the wheels. Meanwhile, traction control systems are monitoring wheel slip in milliseconds so you don’t spin out into a ditch. And let’s not even talk about what happens when you turn that circular wheel in front of you.
It’s effortless for you. It’s a logistical nightmare for the machine.
What about social systems? We all love to complain about the soul-crushing inefficiency of government offices. Why on earth does it take a month to get a passport?
Well, because when you hand over that paper form at the desk, you trigger a massive bureaucratic state machine. Someone has to verify that you actually have the right to hold this document. They have to check that it’s not a duplicate. They have to assign a unique national identification number. And manufacturing that little booklet isn’t a matter of hitting Ctrl + P on a cheap office inkjet printer.
Now, whether these bureaucratic processes are actually designed to make the citizen’s life easy is highly debatable. Personally, I often get the distinct feeling they are designed to do the exact opposite. But the complexity itself is unavoidable.
Who is Supposed to Solve the Problem?
Which leads us directly to the core argument here.
I’m listing these examples to point out one fundamental truth: complexity is conserved. It does not vanish; it is merely shifted from one side of the equation to the other.
This is a vital lesson for software development (and product design in general). We too often fall into the lazy trap of saying, “Well, how are we supposed to know what the user wants? Let’s just give them a configuration toggle.” Or worse, “Let’s just expose a raw config file.”
When you say that, what you are actually saying is: “We don’t want to do our jobs, so let’s make the user suffer instead.”
As a Team Lead, I have spent years drilling this into my teams: as service providers, we must take full responsibility for the user’s experience. Spending an extra week refining a system to remove friction isn’t an optional luxury—it’s basic professional hygiene.
Sure, there are scenarios where a power user actually wants a more complex, customizable solution. But that must be a conscious, researched trade-off, not a default excuse for lazy engineering.
Simple for Whom?
We need to keep this in mind, especially today, as we are flooded with tools that claim to make everything “magically simple.”
AI is fantastic, but it is not magic. It doesn’t magically solve the underlying issues of security, scalability, or performance. It does an incredible job of hiding them, but make no mistake: the chaos is still very much there under the hood. And the “decisions” these models make on our behalf aren’t always the best ones.
So, the next time some tech evangelist tells you that AI makes everything simple, ask them one simple question:
Simple for whom?
But that’s a rant for another day—one I’ll probably write in a few weeks.
In the meantime, if you want to see what happens when we completely forget the importance of building interfaces that hide complexity… well, I dedicated the entirety of Part XI in Fuckup Almanac vol 2 to exactly that. It’s coming out in just a few weeks. Stay tuned.
The hero image is a photograph of Larry Tesler taken in July 2007 by Yahoo! Blog (Sunnyvale, California, USA).
Yes, I used copy/paste to embed it here — for once, I can claim it’s a tribute rather than laziness.
[License: Creative Commons Attribution 2.0 Generic. Source: Wikimedia Commons]
Tesler's Law & Larry Tesler
Primary and secondary sources on the Law of Conservation of Complexity and its author.
4 sources
Tesler's Law & Larry Tesler
Primary and secondary sources on the Law of Conservation of Complexity and its author.
- nomodes.com (Larry Tesler's personal site) Larry Tesler ca. 1984 Accessed: 2026-05-18
Primary source. Tesler's own page with the canonical formulation of the law: 'Every application has an inherent amount of irreducible complexity. The only question is: Who will have to deal with it—the user, the application developer, or the platform developer?'
- nomodes.com (Larry Tesler's personal site) Larry Tesler Accessed: 2026-05-18
Primary source. Lists law as 'ca. 1984'. Also contains the famous misquote about AI ('AI is whatever hasn't been done yet') and Tesler's correction.
- Medium David Chen 2024 Accessed: 2026-05-18
Good secondary overview placing law in context of Apple and MacApp development.
- Wikipedia Accessed: 2026-05-18
Biographical source. Covers PARC work, Gypsy, cut/copy/paste, Apple Lisa, Newton, MacApp, and career at Amazon and Yahoo.
Gypsy editor & cut/copy/paste
Sources on the origin of cut, copy, paste, and the clipboard metaphor.
3 sources
Gypsy editor & cut/copy/paste
Sources on the origin of cut, copy, paste, and the clipboard metaphor.
- Computer History Museum Justin Atkinson, Max Plutte, Hansen Hsu, David C. Brock, Larry Tesler, Jon Plutte 2017 Accessed: 2026-05-18
Archival footage of Tesler demonstrating Gypsy on the restored Xerox Alto, September 2017. Primary source for cut/copy/paste implementation.
- Fast Company Mark Wilson 2020 Accessed: 2026-05-18
Covers Tesler's 'NO MODES' philosophy, the secretary usability research that led to Gypsy, and the physical cut-and-paste origin of the terminology.
- Domestika Alessandra Cesarato 2020 Accessed: 2026-05-18
Confirms Tesler named the functions and coined 'clipboard'. Good concise overview.
Further down the rabbit hole (if you insist)
For the curious and possibly masochistic: detailed technical explainers of the mechanisms described in the post. Read at your own risk.
4 sources
Further down the rabbit hole (if you insist)
For the curious and possibly masochistic: detailed technical explainers of the mechanisms described in the post. Read at your own risk.
- MDN Web Docs Accessed: 2026-05-18
Mozilla's authoritative explainer: DNS, HTTP, TCP/IP, and what actually happens between URL and rendered page.
- eEvidence 2025 Accessed: 2026-05-18
Step-by-step walkthrough of SMTP handshake, MTA chain, and delivery. Includes real protocol conversation example.
SMTP is a protocol responsible for sending emails only. If you're interested with receiving them look for IMAP and POP3.
Note: If you think I'm being ironic, keep in mind that the "S" in SMTP stands for "Simple." (for full spec google rfc5321)
- HowStuffWorks Jamie Page Deaton & Kristen Hall-Geisler Accessed: 2026-05-18
Covers ABS sensors, ECU wheel-speed monitoring, and how TCS decides to cut power or apply brakes. Written with appropriate sardonic tone.
- U.S. GAO 2025 Accessed: 2026-05-18
Official GAO report on passport adjudication pipeline. Includes specialist workflow, intake processing, and systemic backlog analysis. US-centric but illustrates bureaucratic complexity universally.
This is for USA but believe me – it does not get easier in other countries.



