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. There's an equal and opposite failure that's much 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. Relaxing a principle in a given context isn't an absence of rigour, and if you do it properly it's a higher form of it.

Two Failure Modes, Not One

The cargo cult post described a single failure, practices without understanding. 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, and when the practice fails you have no way to find out why.

Failure mode two: applying a practice you do understand, in a context where the problem it solves doesn't exist. You understand that microservices solve independent deployability at scale, and you understand the trade-offs. 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 and the second is rigidity. They produce different symptoms and the same outcome: wasted effort, and systems that don't serve their users well.

The cargo cult test asks whether you can explain why you're doing this. The pragmatist's test extends it, and asks whether you can explain why you're doing it here, given these constraints.

Defining Pragmatism

Pragmatism gets confused with two other things. The first is recklessness: taking shortcuts without any awareness of what you're giving up, making decisions where you can't name the trade-off because it never occurred to you that there was one. The second is the absence of principles altogether. Pragmatism is neither. It's the application of an additional principle, that the value of any practice is conditional on context, and that context has to be evaluated rather than 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.

Miss any of them and the decision isn't pragmatic. It's reckless if you can't name the trade-off, and arbitrary if 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, taking shortcuts because they're faster rather than because they've been evaluated, and never asking what's being given up. The purist is the inverse, applying principles uniformly regardless of context because they're treated as unconditional laws rather than as responses to specific problems, and never asking whether the problem exists here either.

Pragmatism sits between them. That positioning is misleading if you read it as "easier". It's 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, and 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 and others protect against failures that aren't. Input validation, authentication and data integrity all cost very little to apply correctly and can cost enormously if you skip them. 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, and if you're wrong you fix it in an afternoon. Others create coupling that compounds, so that changing the database schema now requires changing the API, the frontend and 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. "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 get to that sentence, you're skipping something because it's inconvenient, which is recklessness with a better vocabulary.

The Symmetry

There's a symmetry here 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 says every practice should have a specific, articulable reason for being followed. The pragmatist's extension says every deviation from a practice should have a specific, articulable reason for being made. Those are the same test applied in opposite directions, and together they make one standard: every engineering decision, whether it follows a principle or deviates from it, requires a justification that references the specific context.

The cargo cult engineer fails the first test by following practices without reasons. The purist fails the second by refusing 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 at all. You do what seems easiest.

Purism requires knowledge of principles without any judgement about their applicability. You learn the rules and you apply them, which feels rigorous, in the same way that applying a formula without checking whether its assumptions hold is rigorous. It's consistent without being correct.

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

The purist knows that you should separate concerns. The pragmatist knows why, that different rates of change in the same unit create cascading modifications, and can therefore spot the situations where the rates of change are actually the same and separation would add complexity for nothing. That's why I think pragmatism is better understood as a deeper engagement with principles 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 which property of the system, which 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.

Which raises the obvious next question. If every engineering decision requires a justification that references context, how do you know whether the justification is actually correct? It isn't enough to have a reason. The reason has to be testable, and that's where the series goes next.