Boat Anchor

A Boat Anchor is a component, dependency, system, or piece of infrastructure that is retained even though it no longer provides value. Like a heavy anchor carried on a boat that never drops it, it adds weight and risk while serving no current purpose. It is kept out of inertia, sunk-cost reasoning, or vague fear that removing it might break something — never out of present need.

Why It Happens

Boat anchors accumulate because deleting things feels riskier than keeping them, and no one is rewarded for removal. A feature is decommissioned but its code, tables, and infrastructure linger. A library is replaced but the old one stays in the dependency tree "just in case." An expensive system was bought and is kept running to justify the purchase, even though nothing depends on it anymore. Lack of ownership means no one is responsible for noticing that a component has outlived its usefulness. Documentation rarely records why something exists, so future engineers fear removing what they do not understand.

Why It Hurts

Every retained component carries ongoing cost. Unused code still has to be compiled, scanned, and kept compatible during refactors, slowing every change. Obsolete dependencies are a prime source of security vulnerabilities — they are unpatched precisely because no one is paying attention. Idle infrastructure incurs real money and operational risk. The dead weight increases cognitive load: engineers waste time understanding code paths that are never executed. Boat anchors also block upgrades, since a stale dependency can pin the whole system to an old runtime or framework version.

Warning Signs

• Code, tables, or services exist that nothing currently calls or reads.
• Dependencies are present "just in case" with no active usage.
• Infrastructure runs with no clear consumer.
• The team keeps something because it was expensive, not because it is needed.
• No one can explain why a component is still there.

Better Alternatives

Practice dead-code elimination and dependency pruning as routine hygiene, supported by usage analysis and coverage data. Treat continuous refactoring as part of normal work so removal is low-drama. Maintain ownership and lightweight records of why components exist, so obsolescence is noticed and acting on it is safe.

How to Refactor Out of It

First, establish that the component is truly unused: check call graphs, runtime telemetry, access logs, and dependency analysis rather than guessing. For anything ambiguous, instrument it to confirm zero usage over a representative window. Remove in safe increments — disable or feature-flag first, observe, then delete the code, data, and infrastructure together. Use version control as the real safety net: the code is never gone, just removed from the active system, so "just in case" is already covered. Decommission paid infrastructure to recover cost. Make removal a celebrated, normal activity so anchors do not re-accumulate.