We often use “feature factory” as a derogatory term. It evokes toxic culture, unsustainable pace, and shipping at the expense of quality.
But it also makes us ask: what is a feature?
Adding code to a codebase doesn’t automatically create a feature. A feature only exists when it’s in the hands of customers, delivering value. Code is not born a feature—it becomes one once customers use it and benefit from it.
The recurring LinkedIn debate about whether Scrum Masters should be technical feels increasingly sterile, especially given the widespread incompetence in the role today.
Yet it’s a fascinating argument because it reveals how fundamentally misunderstood the coaching aspect of this role remains.
A Scrum Master is primarily a coach. The guide explicitly states that Scrum Masters serve the team by “Coaching the team members in self-management and cross-functionality.”
They serve the organisation by “Leading, training, and coaching the organisation in its Scrum adoption.”
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.
We often get into debates about technical practices. Some people get stuck on abstractions, unable to connect them to how they generate money for a business.
I’ve heard the same arguments countless times: “Customers don’t care about clean code!” “The business doesn’t care about your fancy tests!” “Forget TDD, you need to deliver!”
I get where this comes from. To someone outside the engineering bubble, those practices can sound like academic rituals, not business enablers.
I often hear engineers complain about inefficiencies in their pipelines. And they’re right — most companies that claim to do “CI/CD” (and even demand it in job specs) aren’t actually doing either.
CI means integrating into trunk several times a day. CD means always keeping the system in a releasable state. Both exist to help us go to production often.
CD doesn’t always mean every commit hits production, but if releases don’t happen in a continuous way, those practices lose their meaning.
Names are imperfect and often problematic. Personally, I’m not a fan of terms like “unit tests”, “integration tests” or even “acceptance tests”. They always seem to carry slightly different meanings depending on the context.
I prefer to focus on the attributes of tests. That’s why I think we need a testing hypercube, not just a testing pyramid: multiple dimensions defining tests as fast/slow, wide/deep, deterministic/non-deterministic, and so on.
A test can occupy a combination of these dimensions.
