Why Does 'Simple' Win Every Argument?

In the fourteenth century, a Franciscan friar named William of Ockham wrote something that would outlive him by seven hundred years. The principle is famous. You’ve heard it. You’ve probably quoted it.

Except you haven’t. The version you know, “entities must not be multiplied beyond necessity,” was never written by Ockham. It was attributed to him centuries later by a scholar named John Punch, who called it a “common axiom.” The actual words from Ockham’s work are different, more careful, more specific: pluralitas non est ponenda sine necessitate. Plurality should not be posited without necessity.

Notice anything? The original says: don’t add things unless there’s a reason. The popular version says: fewer things are better. Are those the same statement? One is a principle of intellectual discipline. The other is a preference wearing a monk’s robe.

A principle about simplicity got oversimplified. By whom? By everyone who needed a famous name to attach to something they already wanted to believe.

Why does that matter? Because the same thing happens in a meeting room near you, roughly once a week.

The three-second window

Someone proposes an architecture. It has moving parts. Services that talk to each other. Infrastructure that needs configuration. Deployment pipelines with more than one step.

Someone else says: “Can we keep it simple?”

The room nods. The proposal loses momentum. The conversation moves on.

What just happened? Was an argument made? Was a counterproposal offered? Was there a technical evaluation of trade-offs, a cost comparison, a risk assessment?

No. A word was said. And the word was enough.

Think about that for a second. In a discipline that prides itself on logic, precision, and evidence-based decision-making… a single undefined word can end a technical discussion. Not because the discussion was resolved. Because the word created the feeling of resolution. Like nodding at a quote you’ve never actually read.

When was the last time someone said “let’s keep it simple” in a meeting you were in, and anyone… anyone at all… asked: “What do you mean by simple?”

Simple for whom?

Here’s an exercise. Think about the last system you called simple. Not a system someone else called simple. One you, personally, looked at and thought: that’s clean. That’s straightforward. That’s simple.

Now ask yourself: when did you first encounter that pattern? How many years have you spent working with that type of architecture? How many times have you deployed something shaped like that?

Is it simple? Or is it familiar?

Because those feel identical from the inside. The fluency is the same. The comfort is the same. The confidence is the same. But one is a property of the system, and the other is a property of your experience with it. Can you tell them apart from where you’re sitting?

A deployment script that SSHs into a box and runs docker run -d is simple. Until you’re not the one who wrote it. Until someone needs to understand what’s running, why, and how to change it. Until someone needs to find the Dockerfile that built that container somewhere in the system. Until the person who typed the command leaves the company and the system becomes a black box that happens to work.

A Terraform configuration with state files, modules, and a CI pipeline is complex. Until you read it. Until you realize that everything the system does is written down, declaratively, in files that explain themselves. Until a new engineer onboards in a day because the infrastructure is a document, not a secret.

Which one is simpler? And simpler for whom… the person deploying today, or the person debugging at 3 AM six months from now?

Does the comfort zone have an architecture?

There’s a pattern I keep seeing. Once I noticed it, I couldn’t stop.

The same engineer who dismisses Kubernetes as “overengineered” will mass-adopt whatever framework topped Hacker News last month. The same team lead who insists on a monolith for “simplicity” is running a codebase where changing the login page breaks the payment flow. The same architect who says “we don’t need microservices at our scale” has fifteen developers waiting in line to merge into a single branch, deployments that require a calendar invite, and a rollback procedure that starts with “call Dave.”

Do you see it?

What if “simple” doesn’t mean fewer parts? Doesn’t mean less effort? Doesn’t even mean easier to understand? What if it means: I already know how to do it this way?

And what if “overengineered” doesn’t mean more than the problem requires? What if it means: more than I would have done?

Are those technical assessments? Or are they autobiographies? When someone says “that’s overengineered,” are they telling you about the system, or about themselves?

Maybe your experience is a valid lens. Maybe “I know how to do it this way” correlates strongly enough with “this is the right way” that the shortcut works most of the time. But if that’s the argument, why not say it out loud? Why not say “I’m more comfortable with this approach” instead of “this is simpler”? Why dress a personal preference in the language of engineering principles?

KISS, and the S nobody reads

Everyone knows KISS. Keep It Simple, Stupid. It’s on t-shirts. It’s in code review comments. It gets dropped into Slack threads like a trump card.

But what does “stupid” mean in that acronym? It’s not an insult. It’s a standard. Keep it simple enough that even the least prepared person in the room can understand it. The “stupid” is the audience, not the builder. It’s a design constraint that says: your cleverness is not the point. Comprehension is.

So how often is KISS invoked to justify comprehension? And how often is it invoked to justify not learning something new?

“We should use a monolith. KISS.” Does a monolith with forty developers, a two-hour build, and deployment windows at midnight satisfy the “stupid” test? Can the newest person on your team understand the deploy? Can they roll back a change without calling someone? Can they explain the dependency graph?

Or is the monolith “simple” because the people who built it five years ago understood it five years ago?

Ockham didn’t say “fewer is better.” He said “don’t add without reason.” KISS doesn’t say “do less.” It says “make it comprehensible.” Both principles demand rigorous thinking about what is actually necessary. Both get used, in practice, to avoid thinking altogether.

When did a principle designed to sharpen thought become a tool for stopping it?

What does the most expensive word in engineering cost?

I’ve sat in enough architecture reviews to notice a rhythm. The proposal goes on the whiteboard. Questions start. Trade-offs surface. The conversation gets uncomfortable because someone is about to admit they don’t understand part of the proposal, or that implementing it would require learning something they don’t know yet.

And then someone says it. “Let’s keep it simple.”

The relief in the room is almost physical. Shoulders drop. People lean back. The hard conversation just got canceled, and it only cost three words.

But what was the actual cost?

The team that chose the “simple” deployment… what happens when they need to scale? When they need to onboard someone new? When the person who set it up leaves? Was the simplicity free, or was it a loan? Did it feel free on day one while the interest payments started at month six?

The team that chose the “overengineered” setup… what happened? Slower start. More upfront thinking. More configuration. More things that look, to someone who hasn’t read them, like unnecessary complexity. But six months in? New hires read the infrastructure like a document. Changes go through pull requests. State is shared. Knowledge isn’t locked in anyone’s head.

Which team made the simple choice?

What would Ockham actually ask?

The real Ockham’s Razor is not a weapon. It’s a question. It doesn’t say “choose the simpler option.” It says: before you add something, ask whether it’s necessary.

But doesn’t that question cut both ways? Yes, it asks whether the Kubernetes cluster is necessary. But doesn’t it also ask whether the hand-rolled bash scripts that replace Kubernetes are necessary? Whether the monolith is necessary? Whether the “simplicity” itself is necessary, or whether it’s just the path of least discomfort for the people in the room right now?

Ockham was a philosopher. Philosophers don’t end arguments. They make them harder to escape.

So what would Ockham do in your architecture meeting? Would he nod when someone said “let’s keep it simple”? Or would he ask the question nobody wants to answer: “You keep using that word. What do you mean by it? And is it the same thing the person next to you means?”

The word nobody defines

The strangest thing about “simple” is how confidently people use it. Not as an opinion. As a fact. “This approach is simpler.” Said with the same tone as “this server has more RAM.” As if simplicity were a measurable property. As if it existed in the system instead of in the relationship between the system and the person looking at it.

If I hand you a Terraform configuration in a language you’ve never seen, it looks complex. If I hand you a bash script that does the same thing, it looks simple. Same outcome. Same system. Different feeling. And the feeling is what gets called “simple.”

Is that engineering? Or is that comfort, measured in familiarity, presented as analysis?

I’m not saying familiar is wrong. I’m not saying complex is better. I’m not making an argument at all. I’m just noticing something.

When you say “simple”… you know exactly what you mean. The person across the table nods, and they know exactly what they mean. And neither of you has checked whether those two meanings have anything in common.

If you can’t define it, and the person across the table can’t define it, and you both nodded when someone said it… what exactly did you just agree on?