The Pragmatist's Razor

The cargo cult post established a principle: a practice is only justified if you can articulate the specific problem it solves in your context. If you can't, you're performing a ritual, not engineering. The teacher and the doer post went further into what that kind of understanding actually looks like, the difference between being able to apply a rule and being able to explain why it exists.

That principle is correct. But it's incomplete. It addresses one failure mode (applying practices without understanding) while leaving the opposite failure mode untouched: understanding a practice perfectly, and applying it in every context regardless of whether the problem it solves exists there.

This post argues that the same standard of justification that applies to adopting a practice also applies to how rigidly you apply it. And that the decision to relax a principle in a given context is not the absence of rigour. It is a higher form of it.

Two Failure Modes, Not One

The cargo cult post described a single failure: practices without understanding. But there are two distinct ways to misapply knowledge of a practice.

Failure mode one: applying a practice you don't understand. This is the cargo cult problem. You adopt microservices because successful companies use microservices. You don't know what problem microservices solve, so you can't evaluate whether you have that problem. The practice fails, and you don't know why.

Failure mode two: applying a practice you do understand, in a context where the problem it solves doesn't exist. This is different. You understand that microservices solve independent deployability at scale. You understand the trade-offs. But your team is five people, your deployment pipeline is simple, and you have no scaling pressure. You apply the practice anyway, because the principle says you should, and principles are principles.

The first failure is ignorance. The second is rigidity. They produce different symptoms but the same outcome: wasted effort and systems that don't serve their users well.

The cargo cult test asks: "can you explain why you're doing this?" The pragmatist's test extends it: "can you explain why you're doing this here, given these constraints?"

Defining Pragmatism

To reason about pragmatism precisely, it helps to distinguish it from two things it is often confused with.

Pragmatism is not recklessness. Recklessness means taking shortcuts without awareness of what you're giving up. A reckless decision is one where you can't name the trade-off, because you didn't consider that there was one.

Pragmatism is not the absence of principles. It is the application of an additional principle: that the value of any practice is conditional on context, and that context must be evaluated, not assumed.

A pragmatic decision has three properties:

1. You can name the principle you're choosing not to follow.
2. You can explain why the problem that principle addresses is either absent or less important than a competing concern in this specific situation.
3. You can describe the conditions under which you would revisit that decision.

If any of these is missing, the decision isn't pragmatic. It's either reckless (you can't name the trade-off) or arbitrary (you can't explain the reasoning).

The Spectrum

This gives us three positions on a spectrum.

Recklessness is at one end. Decisions are made without reference to principles at all. Shortcuts are taken because they're faster, not because they've been evaluated. The question "what are we giving up?" is never asked.

Purism is at the other end. Principles are applied uniformly regardless of context. The question "does this problem exist here?" is never asked, because the principle is treated as unconditional rather than contextual.

Pragmatism sits between them. It requires more knowledge than either extreme, because you need to understand the principle (which the reckless engineer doesn't), and evaluate whether it applies (which the purist doesn't).

This is an important point: pragmatism is not the easy middle ground. It is the most demanding position. The purist can apply the same rules everywhere without thinking. The reckless engineer can ignore rules everywhere without thinking. The pragmatist has to think every time.

When to Hold and When to Relax

If pragmatism means "principles are conditional on context," you need a way to evaluate when the condition is met. Three factors matter.

The cost asymmetry of getting it wrong. Some principles protect against failures that are cheap to fix. Others protect against failures that are catastrophic. Input validation, authentication, and data integrity fall into the second category. The cost of applying these principles correctly is small. The cost of not applying them can be enormous. When the downside of relaxing a principle is high relative to the cost of following it, follow it. The asymmetry does the reasoning for you.

Whether the shortcut is local or structural. Some deviations from a principle affect one file, one function, one component. If the decision turns out to be wrong, you fix it in an afternoon. Other deviations create coupling between systems that compounds over time. Changing the database schema now requires changing the API, the frontend, and the deployment pipeline. The first kind of deviation is low-risk and often pragmatic. The second kind is high-risk and rarely pragmatic, because the cost isn't borne at the time of the decision. It's deferred, and deferred costs tend to grow.

Whether you can articulate the trade-off. This is the test that connects back to the cargo cult principle. In the previous post, I argued that a practice is only justified if you can explain the problem it solves. The same applies to deviations. A pragmatic deviation is one where you can say: "I'm choosing not to do X because the problem X addresses doesn't apply here, and applying it anyway would cost Y." If you can't articulate it that precisely, you're not being pragmatic. You're just skipping something because it's inconvenient, which is recklessness with a better vocabulary.

The Symmetry

This reveals a symmetry between the cargo cult problem and the purism problem that I didn't fully see when I wrote the first post.

The cargo cult test: every practice should have a specific, articulable reason for being followed.

The pragmatist's extension: every deviation from a practice should have a specific, articulable reason for being made.

These are the same test applied in opposite directions. Together they form a single standard: every engineering decision, whether to follow a principle or to deviate from it, requires a justification that references the specific context.

The cargo cult engineer fails the first test. They follow practices without reasons. The purist fails the second test. They refuse to deviate without acknowledging that reasons could exist. The pragmatist passes both.

Pragmatism as the Harder Skill

This framing explains why pragmatism is harder to develop than either purism or recklessness.

Recklessness requires no knowledge of principles. You just do what seems easiest.

Purism requires knowledge of principles, but not judgement about their applicability. You learn the rules and apply them. This feels rigorous, and it is, in the same way that applying a formula without checking whether the assumptions hold is rigorous. It is consistent without being correct.

Pragmatism requires knowledge of principles and the ability to evaluate their relevance to a specific context. You need to understand what problem the principle solves well enough to recognise when that problem is absent. This means understanding the principle more deeply than the purist does, not less.

The purist knows that you should separate concerns. The pragmatist knows why you separate concerns (because different rates of change in the same unit create cascading modifications), and can therefore identify situations where the rates of change are actually the same and separation would add complexity without benefit.

This is why I think pragmatism is better understood as a deeper engagement with principles rather than a looser one. The pragmatist doesn't care less about good engineering. They care enough to distinguish between the principle and the context that gives it value.

A Decision Framework

When I'm evaluating whether to follow or deviate from a principle, I try to answer three questions:

What specifically am I trading off? Not vaguely "code quality," but precisely. What principle, what property of the system, what future capability am I choosing to forgo or defer?

What is the cost if I'm wrong? If this turns out to be a mistake, how expensive is it to reverse? A decision that can be undone in an afternoon carries different weight than one that's baked into the architecture.

Can I explain this decision in six months? If I can't imagine justifying this to a colleague or to my future self, it probably isn't a reasoned trade-off. It's a shortcut dressed up as pragmatism.

If all three answers are clear, the decision is pragmatic whether it follows the principle or deviates from it. If any answer is vague, that's a signal to think harder before committing.

What This Means for the Series

The cargo cult post established that understanding is necessary for good engineering. This post adds that understanding is necessary but not sufficient. You also need the judgement to evaluate when and how strongly a principle applies.

The next question follows naturally: if every engineering decision requires a justification that references context, how do you know whether that justification is actually correct? It's not enough to have a reason. The reason has to be testable. That's where the series goes next.