Fake Pragmatism

I’ve just read this in a LinkedIn comment: “Same story for TDD. No business wants a suite of unit tests, they want quality for sure, that’s why they hire the best developers, they want products shipped that work reliably, not a product that never gets delivered but has 95% test coverage.”

Fake pragmatism dressed up as business sense.

Every time someone says “no business cares about test suites” to dismiss TDD, all it really shows is a lack of understanding.

TDD is not about producing tests as deliverables. That’s a category error.

The fallacy here is confusing by-product with purpose. The tests exist, yes, but they’re a side effect. The actual purpose is guiding the design step by step, granular behaviour by granular behaviour.

Then there’s the false equivalence between “tests” and “waste”. The assumption is that if business owners don’t directly value a test suite, then tests must be overhead. But the real cost to the business is firefighting, delays, unreliability, rework, outages, bugs, and brand damage. TDD tackles those at the source.

There’s also a straw man in play: the idea that TDD is something imposed on the business, like “hey, please fund my giant golden test suite.” That’s not it.

TDD is a private engineering tool. Nobody outside the team needs to even know it’s being used. It’s not up for business debate. It’s simply part of how competent engineers deliver working, reliable software.

And perhaps the biggest fallacy of all: short-termism disguised as pragmatism.

Cutting corners on quality in the name of speed always creates the opposite: slower delivery, higher costs, and endless fire drills. TDD, done well, is one of the most powerful ways we have to ship both fast and reliably.

So when someone says “no business cares about tests”, what they’re really saying is they haven’t understood what TDD is, why engineers use it, or what actually costs businesses the most.

Finally: We need to stop framing companies as if “the business” is the brain and engineers are just the arm. That mindset creates a master-slave dynamic where the so-called business demands and developers scramble to execute, even if that means shipping rubbish.

In reality, we all are the business. Engineering is not a separate servant function, it’s an integral part of how value gets created. When we treat it otherwise, we don’t get pragmatism, we get toxicity. And products nobody’s proud of.

Originally posted on LinkedIn.