Is Feature Factory That Bad?

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.

Code that is never activated, never used, never adds value, never becomes a feature. It’s just dead weight the product drags around.

That’s why getting to production quickly matters. The faster an idea reaches customers, the faster it becomes a feature.

Do we want to release real features and not imagined ones? Let’s shorten the time from commit to production more and more.

If we define features this way, a “feature factory” wouldn’t be bad at all: it could be a continuous stream of valuable behaviours that customers can use, deriving real value.

Like a well-run factory that cares about product quality and the wellbeing of its workers, a healthy feature factory would combine quality, sustainable pace, and strong support—exactly what the Agile Manifesto calls for.

What we really mean by “feature factory” today, though, is a rusty conveyor belt churning out low-quality code and making developers’ lives miserable.

Every piece of code should carry a metric that counts how often it’s exercised in production. After months of customer use, we can see what parts of our code deliver real value—and which parts are better revisited.

Originally posted on LinkedIn.