The Pragmatist's Razor

The cargo cult problem is easy to describe: you adopt a practice you don't understand, and when it fails you don't know why. But there's an equal and opposite failure that's harder to see: understanding a practice perfectly, and applying it in every context regardless of whether the problem it solves exists there.

The same standard of justification that applies to adopting a practice applies to how rigidly you apply it. 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

Pragmatism gets confused with two other things. The first is recklessness: taking shortcuts without awareness of what you're giving up, decisions where you can't name the trade-off because you didn't consider there was one. Pragmatism is not that. The second confusion is with the absence of principles altogether. Pragmatism is not that either. It's 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

The reckless engineer and the purist are mirror images of each other. The reckless engineer makes decisions 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?" never gets asked. The purist is the inverse: principles are applied uniformly regardless of context, because they're treated as unconditional laws rather than responses to specific problems. The question "does this problem exist here?" never gets asked either.

Pragmatism sits between them, but that positioning is misleading if you read it as "easier." It's actually the most demanding position on the spectrum. 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. Thinking takes more effort than either consistency or indifference.

When to Hold and When to Relax

Three things tend to determine it. The first is the cost asymmetry of being wrong. Some principles protect against failures that are cheap to fix; others protect against failures that aren't. Input validation, authentication, data integrity: the cost of applying these correctly is small; the cost of not applying them can be enormous. When the downside of relaxing a principle significantly outweighs the cost of following it, that asymmetry does most of the reasoning for you.

The second is whether the shortcut is local or structural. Some deviations affect one file, one function, one component; if you're wrong, you fix it in an afternoon. Others create coupling that compounds: changing the database schema now requires changing the API, the frontend, the deployment pipeline. The first kind is often pragmatic. The second rarely is, because the cost isn't borne at the moment of the decision. It's deferred, and deferred costs grow.

The third is whether you can articulate the trade-off precisely. Not vaguely. Precisely. "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 reach that sentence, you're not being pragmatic. You're 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 a decision like this, three questions do most of the work. What specifically am I trading off, not vaguely "code quality" but precisely: what property of the system, what future capability am I choosing to forgo? If this turns out to be wrong, how expensive is it to reverse: an afternoon's work or something baked into the architecture? And can I explain it in six months, not just to a colleague but to my future self who has forgotten the context?

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

If every engineering decision requires a justification that references context, the next question follows: 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.