Seattle

Bottom line. Before building anything, write the problem in one sentence with no technology in it, then ask what can be removed before anyone proposes an addition. The complicated version is the cheap one to produce. People default to adding. In a 2021 study published in Nature, most participants asked to stabilize a Lego structure paid for extra bricks, when pulling out a single brick would have fixed it for free. AI coding assistants make the habit worse: new code now costs almost nothing to write.

A simple system takes more thinking before the first commit. Every debugging session, onboarding and incident after that goes faster. You will come away with the research on why teams default to adding, what Brooks, Hickey, Gall and Hoare said about the cost, what AI changes, and six habits that get a team to the purest form of a problem.

Building something complicated is easy. Hand a team a vague problem and a deadline, and within a sprint the design has a new service, two feature flags, a config file and a weekly meeting to explain the config file.

Building something simple means understanding the problem well enough to tell which parts of it are real, then throwing out everything else, including pieces you already paid for.

So the complicated version ships first, and then it stays. A year later it has owners, callers and a runbook, and taking it out needs a project plan of its own.

Break every problem down to its purest, simplest form before you build anything, and keep breaking it down while you build.

Ten Cents a Brick

In 2021, Gabrielle Adams, Benjamin Converse, Andrew Hales and Leidy Klotz published People systematically overlook subtractive changes in Nature. One of their experiments used a Lego structure: a roof held up by a single pillar at one corner, sitting over a stormtrooper figurine. Participants had to change it so a masonry brick could sit on top without crushing the figure.

Each Lego brick they added cost ten cents out of their pay. Removing bricks cost nothing. Pull out the right one and the platform drops flush onto the base, still clear of the stormtrooper.

In the control group, 59 percent bought bricks and added them. A second group heard one extra sentence from the experimenter, that removing pieces was free. Both groups already knew it. The share who added fell to 39 percent.

The team ran the same test on essays, recipes, travel itineraries and miniature golf holes. In one study, additive suggestions outnumbered subtractive ones eight to one, and people overlooked subtraction more often when they were rushed or distracted.

Engineering teams spend most weeks rushed and distracted. Two-week sprints, incident pages at 2 a.m. and on-call rotations put them under the same conditions in which the study’s participants stopped seeing the free option.

Essence and Accident

Fred Brooks split complexity into two kinds in his 1986 essay “No Silver Bullet: Essence and Accident in Software Engineering.” Essential complexity comes from the problem itself. A payroll system has to calculate withholding across federal, state and local tax rules, and that work exists whatever language or architecture you pick. Accidental complexity is everything the team adds on top: the tools, the abstractions, the deploy pipeline, the framework somebody picked four years ago.

Take a request to tell customers when their order ships. Solving it takes an event, a recipient and a message. A first design for it can easily include a queue, a preference service, a templating engine, a retry policy, an admin console and a dashboard with forty charts. Which of those belong depends on numbers the team can get today. A retailer sending two million shipping notices on Cyber Monday has the queue and the retry policy in its essential complexity, and they go in the first version. A shop sending four hundred a day does not. Size the design to the load you can measure and write down the volume at which the next piece goes in. The dashboard belongs in the first version too, with only the numbers someone will act on: notices sent, notices failed and the time from shipment to message. Leave the admin console out until somebody asks for it.

Larry Tesler, who worked on interface design at Xerox PARC and Apple, argued that every application has some complexity nobody can delete. It can only be moved onto the user or onto the developer. Find that minimum and build to it. Anything beyond it can go.

Simple Made Easy

Rich Hickey, who created Clojure, gave a talk at Strange Loop in 2011 called “Simple Made Easy.” He went back to the Latin. Simple comes from simplex, one fold or one braid: a thing doing one job, not wrapped around anything else. For easy, he traced the root to lying near. In a codebase that is the familiar framework, or the library already on the classpath.

The complicated system is usually the easy one. The team reaches for the framework it already knows, copies the pattern from the last project and bolts the new feature on wherever the code was already open. Every choice along the way is near at hand, and by the end the billing logic sits inside the notification code.

Hickey’s word for it is complect. Once two concerns are complected, nobody can read, test or change one without the other, and a one-line fix in billing ships a bug in notifications.

Blaise Pascal described the cost in 1657. He closed the sixteenth of his Provincial Letters by apologizing for its length: he had made it longer, he wrote, only because he had not had the time to make it shorter.

What Complexity Costs

Brian Kernighan put a number on clever code in The Elements of Programming Style. Debugging is twice as hard as writing the code in the first place. Write it as cleverly as you can and you are, by his arithmetic, not smart enough to debug it.

John Gall wrote it down as a law in Systemantics in 1975. Every complex system he found in working order had grown out of a simple one. Complex systems designed from scratch failed, and patching them did not help. The way out, he wrote, was to start over with a simple system that worked.

Tony Hoare used his 1980 Turing Award lecture, “The Emperor’s Old Clothes,” to describe two ways to design software. You can make it so simple that it obviously has no deficiencies, or so complicated that it has no obvious deficiencies. Then he gave the cost of the first one: “The first method is far more difficult.”

What AI Changes

AI coding assistants drop the price of the extra brick to almost nothing. GitClear analyzed 211 million changed lines of code written between 2020 and 2024. During 2024, blocks of five or more duplicated lines became eight times more common, and moved lines, which GitClear uses to track refactoring, fell 39.9 percent. It was the first year copy-pasted lines outnumbered moved ones.

The models have also gotten much better at debugging. By August 2026, frontier coding agents scored in the high 70s on SWE-bench Verified, a benchmark built from real bugs in open-source repositories. DDBench, a 2026 benchmark of 60 bugs from 13 distributed systems, tested bugs that cross processes and machines, where the cause rarely shows up in the source. Agents passed 18.1 points more often when someone handed them logs, traces and runtime state.

Human debugging skill is falling. In a randomized trial Anthropic published in January 2026, 52 developers learned an unfamiliar Python library, some with AI help and some without. The AI group averaged 50 percent on a follow-up quiz and the hand-coding group 67 percent, with the widest gap on debugging questions. Participants who handed debugging to the AI scored under 40 percent. In Stack Overflow’s 2025 survey, 45 percent of developers said debugging AI-generated code takes more time.

Kernighan assumed a programmer debugging his own code. With AI in the loop, the person debugging often never wrote the code, and sometimes the debugger is a model. Models do best on contained bugs where the evidence sits in the code, and they need help once a bug spans processes and machines. A simple system keeps more of its bugs in the first category.

Getting to the Purest Form

Six habits get a team there. Use them on every design, including the rushed ones.

  1. Write the problem in one sentence with no technology in it. “Customers know when their order ships” works. Any sentence with a platform, service or vendor name in it has already picked a solution.
  2. List what has to be true for that sentence to be true. Keep the list short. Treat everything else on the whiteboard as accidental complexity and make somebody argue it back in.
  3. Ask for subtraction out loud. One spoken sentence moved the Lego study’s add rate from 59 to 39 percent. Put “What can we remove?” on the design review template as its own line, and require an answer before anyone proposes an addition.
  4. Ship the simple version that works. That might be a script, a cron job or one database table. Add pieces only after production traffic shows you need them.
  5. Count the braids. Every time two concerns depend on each other, write the dependency down. When the list grows faster than the feature set, stop and pull something apart.
  6. Make deletion visible. Pull requests that remove code, services that get retired and recurring meetings that get cancelled go in the same status update as the features that shipped.

Start This Week

Pick one thing you own. A service, a process, a recurring meeting, a dashboard with no viewers in the last ninety days. Write down the problem it solves in one sentence, with no technology in it.

Then ask what breaks if it disappears on Monday, and if nothing much does, turn it off.