THE METHOD
Subtraction before construction.
Most systems do not need more code. They need less duplication, less abstraction, less surface area, and more coherence. The PRUNE method is a five-step discipline for achieving this.
Observe
Map the system as it exists. No opinions. No judgments. Just structure. Catalog every module, function, dependency, configuration, and workflow step. This is reconnaissance, not analysis. You cannot reduce what you have not seen. Observe the full topology before forming any conclusion about what should stay or go.
Diagnose
Classify every element. Each component, module, function, and dependency receives one of six classifications based on its current state in the system.
Actively used, connected to other elements, maintained. This element earns its place.
Unused, unreferenced, abandoned. No part of the system depends on it. Remove immediately.
Rarely used, low activity, fading relevance. Still connected but losing its reason to exist.
Similar or identical to another element. One of them should not exist. Merge or remove.
Exists for appearance of sophistication. Adds complexity without adding function. The most dangerous kind.
High cost, low value. Drains system health through maintenance burden, performance cost, or cognitive load.
Decide
Apply the filters. Every element that survived classification must now pass through five questions. These filters are ordered by severity — start from zero and work up.
“Can this be removed entirely?”
Ask this first. Always. Most elements were added with good intentions and never reconsidered. The zero filter forces the most important question: does this need to exist at all? If the answer is no, stop here. Remove it.
“Is this essential?”
Does the system break without this element? Not "would it be less convenient" — does it actually break? Essential means load-bearing. If the system functions without it, it is not essential.
“Is this symbiotic with the rest of the system?”
Does this element both give to and receive from the system? Symbiotic elements are integrated — they connect, they depend, they are depended upon. Isolated elements that only take resources without contributing are parasitic.
“Is this traceable to a clear purpose?”
Can you point to exactly why this element exists? Not a vague justification — a specific, current requirement. If nobody can explain why something exists, it probably should not.
“Can this be removed later without cascading damage?”
Even if an element passes all other filters today, if removing it later would cause cascading failures across the system, it is a risk. Good elements are loosely coupled — they can be extracted cleanly when their time comes.
Act
Execute the changes. Each diagnosed element receives one of six actions. Prefer deletion. Prefer merging over separation. Prefer inlining over abstraction.
Reflect
Verify the outcome. Run the audit again. Compare before and after. Confirm nothing essential was lost. Document what was removed and why. Reflection closes the loop — it transforms a one-time cleanup into a repeatable discipline. The system should be measurably simpler, more coherent, and easier to reason about. If it is not, you removed too little or the wrong things.
WHY THIS ORDER
Why subtraction comes first.
Building on top of an unaudited system compounds debt. Every new feature inherits the weight of every unnecessary element beneath it. Every new abstraction must account for the decorative ones already in place.
Subtraction reduces surface area. It makes the remaining system smaller, clearer, and more coherent. This makes subsequent construction cheaper, faster, and less likely to introduce new waste.
The discipline is simple: reduce first, then build. Audit before architecture. Simplify before scaling. Remove before adding. This is not minimalism for its own sake — it is engineering discipline applied to the most neglected action in software: removal.