Systems do not become complex. They accumulate complexity — one reasonable decision at a time — until no single person can hold the whole in their head.
Dead code, unreachable branches, and obsolete paths accumulate as geological layers
If understanding a single change requires understanding the entire system — if a class handles responsibilities that span multiple domains — if code exists that no one can explain but no one dares remove — complexity has accreted past the point of comprehension.
Every codebase experiences this. The force driving accretion is time itself — combined with changing requirements, changing teams, and the economics of "just add it here." Refactoring is expensive. Accretion is free. Until it isn't.
Dead code conceals vulnerabilities — a deprecated code path with SQL injection survives because no one dares remove it
God objects accumulate dead branches — as responsibility grows, code paths become unreachable but undeletable
GOTO-heavy code accumulates unreachable branches because no one can trace the control flow well enough to identify what's dead
Year
1993–present
Context
As codebases grow, conditional logic accumulates. A switch statement starts with three cases and grows to twelve. An if-else chain gains new conditions with each feature request. Nobody removes the old branches — they might still be needed. Nobody tests them — they were tested when they were written. Over time, some branches become impossible to reach. The condition that guards them can never be true. The code inside is a fossil — syntactically valid, semantically dead, and confidently shipping to production.
Who Built This
Every developer who ever added a case to a switch without removing old ones. Every team that inherited code and added to it without understanding the full decision tree. Every code review that approved "just one more if" without mapping the logical space.
Threat Model at Time
Functional correctness — does the happy path work? Dead branches don't break the happy path. They don't throw errors. They don't slow anything down. They're invisible until someone reads the code and asks: "Can this branch ever execute?"
Why It Made Sense
Defensive programming. "Handle every case, even the ones you don't expect." The switch statement has a default. The if-else chain has a final else. The intention was robustness. The result was code that looked thorough but couldn't be reached — creating false confidence in coverage.
This pattern has been found in applications built by talented developers at respected organizations across every decade of software history. Its presence in a codebase is not a reflection of the developer who wrote it — it is a reflection of what that developer was taught, what tools they had, and the path that was easiest given what they were taught. The goal is not to find fault. The goal is to find the pattern — before it finds you.
Katie's Law: The developers were not wrong. The shortcut was not wrong. The context changed and the shortcut didn't.