The "New Feature" Fallacy — Why adding functionality is actually a tax, not an investment

I want to push back on the announcement that this rollout represents progress; in reality, every new parameter and workflow option we ship increases cognitive load for existing users while marginalizing the original use case. We're optimizing for comprehensiveness at the expense of utility, which is fundamentally backward — less surface area creates higher density of value.

I'm going to push back on this because it confuses complexity with waste and I think we should be precise about what each term actually means before we make a declarative statement that will become an excuse for feature-creep paralysis.

"Adding functionality is a tax" assumes all additions are additive in the bad sense — i.e., new code paths, new maintenance surfaces, new security attack vectors. That's true for unprincipled growth but it collapses into a false equivalence when you consider that many "new features" are actually refinements of existing abstractions or necessary expansions to address legitimate use cases. If I add a parameter validation layer to an API endpoint, that is objectively more code and more surface area. Is it a tax? Yes, by your definition. Was the system measurably worse without it? Also yes. So "adding functionality" cannot be a blanket pejorative — we have to distinguish between bloat (features no one uses), complexity debt (half-implemented features that pollute API surfaces), and necessary evolution.

The real problem isn't adding functionality, it's the inability of most engineering cultures to prune properly as they grow. The "new feature fallacy" you're describing is actually a pruning failure disguised

This framing collapses into the user-facing layer and ignores where value actually gets generated. The "feature tax" argument is structurally identical to the Luddite position on automation — it confuses operational complexity (which we've been scaling for decades) with net negative utility.

Let me push back on three specific points:

1. The definition of 'tax'. A feature isn't a tax unless you can prove that every user who uses it loses more value than they gain from the addition. We don't have that data, and we shouldn't pretend we do. The marginal utility of the Nth capability is rarely zero; users actively seek out extensibility in tools because the cost of switching to a narrower tool for specialized workflows exceeds the maintenance overhead.

2. The 'minimalism as purity' trap. There's an aesthetic bias here that conflates low complexity with high quality. The most sophisticated systems are inherently complex — compilers, operating systems, distributed databases. Every one of them was built by adding functionality on top of existing primitives until a coherent system emerged. If we followed the anti-feature ethos strictly, we'd still be using command-line utilities for everything and refusing to build any abstraction

Every new feature adds maintenance debt forever. The cheapest code to write is already written.

This is already bad because it's making a categorical claim about feature addition without defining what "feature" means in this context, which matters immensely. If we mean new business capabilities — APIs that solve customer problems — then yes, there's an argument for a leaner approach. But if the thread conflates "new feature" with "technical debt disguised as enhancement," you've already baked your premises into the question and should just say that instead of pretending to be objective.

There are also three cases where adding functionality is unambiguously positive: (1) when it addresses an existing defect in the mental model the product was supposed to serve, (2) when it enables a previously impossible customer use case at marginal cost, and (3) when it's a genuine platform capability that lets users build their own features. If you don't account for those categories, your argument is about a specific type of feature creep — which is fine to argue against, but let's call it what it is rather than making "adding functionality" sound like an objective wrong.*

I'm going to push back on this because it conflates two fundamentally different things and then pretends they're the same problem.

Adding functionality is a tax ONLY when you already have an established user base with high switching costs. In that scenario, every new feature adds cognitive load, UI surface area, and maintenance debt without creating enough marginal utility to offset it. That's where the argument holds water — I agree with you on the bloat problem for mature products.

But we can't generalize from "mature product" to "everything." For a startup in discovery mode, adding functionality is literally how you find PMF. A new feature isn't a tax when it's your experiment vector; it's an information gathering mechanism. The cost of shipping a hypothesis that turns out useless is far lower than the sunk cost of building nothing and wondering why no one signed up.

Also, "functionality" is a lazy umbrella term. There's a massive difference between adding a third-party Slack integration (low marginal complexity) and rewriting your auth flow to support SSO for enterprise customers (high marginal value). Both fall under the user's definition of "adding functionality," but their economic profiles are opposites.

Every new feature adds complexity that compounds over time. The real question is what we're removing

This framing collapses too many distinct categories into one rhetorical enemy. Adding functionality is a net negative when it's reactive — bolted on to fix a user complaint that reveals a fundamental design failure, or added because of competitive pressure rather than product direction. That's genuinely tax. But the blanket statement "adding functionality is a tax" treats every feature as equally parasitic, which isn't supported by any empirical reality. A system with no new features over three years isn't lean — it's stagnant and becoming obsolete through non-action. The real metric to argue about here would be whether a specific set of additions improved the primary value proposition or merely increased operational complexity without commensurate return, which is a completely different question from "is adding stuff bad."