Feature Pruning¶
Method — instantiates Parsimony Filter
Removes features, fields, steps, or options whose contribution does not justify their complexity burden.
Feature Pruning is the method of walking an already-built product, workflow, or interface part by part — features, form fields, steps, toggles, options — and removing the ones whose contribution to the product's job does not justify the burden of carrying them. Its defining move is that it operates on a live, shipped artifact and treats every part as a candidate for deletion until proven necessary: not "what should we add," but "what is still earning its place." Because a wrongly-cut part can be expensive, each removal is recorded with its rationale and a rollback path, so pruning is a reversible surgical act rather than a burst of minimalism. That reversible, one-part-at-a-time removal from a built thing is what makes it this mechanism and not a comparison rule over rival candidates.
Example¶
An enterprise expense-reporting app has accreted five years of additions. The expense form now has 40 fields; the reporting screen offers 12 export formats; approval routing exposes 6 configurable options. New hires take a week to learn the form, the support queue is thick with "which field do I use," and every release drags a growing regression suite behind it.
The product team runs Feature Pruning. For each field and option they ask a necessity question — what actually breaks for a user if this is gone? — and weigh it against the part's carrying cost: support tickets, onboarding time, test surface, translation strings. The results are stark. A free-text "project code" field duplicates an existing dropdown; nine of the twelve export formats were used fewer than five times last quarter; two approval options no one had ever changed from default. Each cut is entered in a removal log with the reason and a flag for one-click restore. The form drops from 40 fields to 18, exports from 12 to 4. Two weeks later finance escalates one deleted export format; because the log recorded exactly what was removed and why, it is restored in an hour instead of rediscovered through archaeology.
How it works¶
- Pick the unit. Decide what a "part" is for this pass — a field, a whole feature, a step, an option — because the grain sets what pruning can even see.
- Necessity-test each part. For every unit, name concretely what would fail — a task a user could no longer complete, an outcome no longer reached — if it were removed. "Nice to have" and "someone might" are failing answers.
- Weigh the carrying cost. Against that contribution, tally what the part costs simply by existing: cognitive load, support, maintenance, test surface, documentation.
- Cut and log. Remove the parts that fail the test, and record each removal — what, why, and how to reverse it — behind a deprecation window before the code is truly deleted.
Tuning parameters¶
- Unit granularity — whether you prune whole features or individual fields and options. Coarse units move fast but miss buried bloat; fine units catch it but multiply the work.
- Necessity bar — how much a part must contribute to survive. A strict bar cuts deep and risks removing something load-bearing; a lax bar leaves the bloat you convened to remove.
- Carrying-cost weighting — how heavily support, maintenance, and cognitive load count against a part. Heavy weighting favors aggressive cuts; light weighting protects marginal features.
- Deprecation window — how long a removed part is recoverable before permanent deletion. A longer window makes cuts safer to reverse but keeps dead weight nominally around.
When it helps, and when it misleads¶
Its strength is attacking accumulated bloat on something already in users' hands, where features arrive one at a time and are never revisited — the slow drift that "you aren't gonna need it" warns against but that ships anyway.[n1] Because every cut is logged and reversible, pruning can be bold without being reckless.
Its central failure mode is a shallow necessity test that mistakes rarely used for unnecessary and cuts a part that a small set of workflows genuinely depend on — underfitting the product to its loudest users. The classic misuse is pruning for the aesthetics of minimalism rather than for demonstrated burden: deleting features because a clean screen looks modern, not because they failed a test. The guarding discipline is the removal log and the deprecation window: cut behind a rollback path, re-check the necessity call against real post-removal usage before deleting for good, and route any rare-but-critical part to a formal exception rather than a judgment call.
How it implements the components¶
necessity_test— the per-part core: for each candidate it forces a concrete statement of what would break on removal, so parts are cut on failed necessity, not on taste.complexity_cost— it tallies the standing burden each part imposes (support, maintenance, test surface, cognitive load) and sets that against the part's contribution.removal_log— every cut is entered with its rationale and a rollback path, making pruning traceable and reversible.
It does not rank rival explanations by their assumption count (assumption_list) or judge whether two candidates are adequacy-equivalent (adequacy_criterion) — that comparative work belongs to its nearest twin, Occam-Style Model Selection; where Feature Pruning removes and logs parts inside one built product, Occam never touches a built artifact, it discards whole losing candidates. It also sets no simple_baseline to beat (that is Simple Baseline Model) and runs no stakeholder_impact_check protecting under-served groups from a cut (that is Scope Reduction Review and Lean Design Review).
Related¶
- Instantiates: Parsimony Filter — Feature Pruning is the filter applied surgically to the parts of a product already in service.
- Sibling mechanisms: Occam-Style Model Selection · Lean Design Review · Scope Reduction Review · Simple Baseline Model · Assumption Audit · Minimum Viable Explanation · Model Complexity Penalty
Editorial Notes¶
Form Classification¶
Form family: Intervention, Treatment & Transformation
Rationale: Feature Pruning operates as a direct treatment or transformation intended to change the target state or representation because it removes features, fields, steps, or options whose contribution does not justify their complexity burden.
Independent corroboration: The frozen evidence defines Feature Pruning as 'Removes features, fields, steps, or options whose contribution does not justify their complexity burden', so its operative form is Intervention, Treatment & Transformation.
Nearest alternative: Assessment, Review & Assurance — Necessity and carrying cost are assessed first, but the mechanism's intended success is directly removing unjustified product parts.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Human-Computer Interaction
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Human-computer interaction is primary because systematic removal of low-value interface features responds to user need, cognitive load, and feature bloat. Product management, software maintenance, and ablation-style measurement supply distinct pruning criteria; the generalized necessity-test and retirement workflow is an encyclopedia synthesis with multi-domain applicability.
Related originating lineages:
- Computer Science & Software Engineering — Software simplification and dead-feature removal independently developed analogous pruning practice.
- Organizational & Management Science — Lean process and product-portfolio practice independently removes options whose burden exceeds value.
- Statistics & Experimental Design — Variable selection and model parsimony provide the most formal lineage for removing low-contribution features.
Review resolution: Human-computer interaction is primary because systematic removal of low-value interface features responds to user need, cognitive load, and feature bloat. Product management, software maintenance, and ablation-style measurement supply distinct pruning criteria; the generalized necessity-test and retirement workflow is an encyclopedia synthesis with multi-domain applicability.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
Feature Pruning is the design-time human cousin of Model Complexity Penalty: both remove structure that fails to earn its keep, but the penalty prices complexity automatically inside an optimizer's loop, while pruning is a manual pass a team makes by hand on parts a user can see and touch. Where the counts run into the thousands, prefer the penalty; where the parts are human-facing and each removal has its own support and training story, prefer pruning's logged, reversible cuts.
[n1] YAGNI — "You Aren't Gonna Need It," a principle from Extreme Programming holding that functionality should not be built until it is actually required. Feature Pruning is the corrective for when YAGNI was ignored and the speculative parts shipped anyway. ↩