The employees who haven't shown up in three years (and are still getting paid)

Imagine an employee — let's call him Gary — who stopped coming to work in 2023. Not dramatically. No resignation letter. He just... stopped. And because your company has no attendance system, nobody noticed.

Gary is still on payroll. Gary still has a desk, and the desk is in the middle of the main hallway, so everyone walks around it several times a day. Gary is still CC'd on everything. When the office moves buildings, movers carefully pack Gary's desk. When you roll out new security training, someone updates Gary's records. New hires, on their first week, spend a genuinely surprising amount of time trying to figure out what Gary does — because surely he does something, he's right there in the org chart — before a veteran quietly tells them, "oh, don't worry about Gary."

Every production codebase is full of Garys. The industry term is dead code, and almost everyone misunderstands what it costs.

The cost is not where you think

The intuitive objection goes: who cares? Dead code doesn't execute. It burns no CPU, serves no requests, throws no errors. It's inert. Deleting it saves nothing measurable, so it's nobody's priority, so it stays. This logic is airtight and completely wrong, because it prices Gary at his electricity usage.

The real cost of dead code is comprehension, and comprehension is the single most expensive thing your engineering org does. Xia and colleagues, in a large-scale field study of professional developers published in IEEE Transactions on Software Engineering, found that developers spend roughly 58% of their time on program comprehension — just understanding existing code, before changing a single line. That is the majority activity of your engineering payroll. Whatever makes comprehension slower is, quite directly, a payroll multiplier.

And dead code makes comprehension slower in a uniquely sneaky way: it doesn't announce that it's dead. A function sitting in a file looks exactly as alive as its neighbors. So every engineer who reads that file — and remember, reading is most of what they do — must either (a) spend effort determining that the function is irrelevant, or (b) fail to determine that, and factor it into their mental model anyway. Both options cost. Option (b) costs compoundingly: the engineer now carries a map of the system with phantom rooms in it, reasons about interactions that cannot happen, and preserves the dead thing during refactors "just in case."

John Ousterhout's A Philosophy of Software Design frames the deep issue: complexity is anything about a system's structure that makes it hard to understand and modify, and it accumulates in small increments. Dead code is the purest increment there is — it adds understanding-burden while contributing literally zero function. It is complexity with no redeeming payload. A live, ugly function at least does a job. Gary doesn't even do that.

How much of your codebase is Gary?

Here's the number that tends to stop people: in CodeNSM's own fleet telemetry, it is routine to find a quarter or more of a codebase's functions completely dormant — defined the boring way: zero production calls over an extended observation window. Not "rarely used." Zero. (Whether that share has a floor across all production systems is one of our pre-registered research hypotheses, so treat the general claim as ours-so-far rather than a law of nature.)

Sit with the shape of that. If your engineers spend most of their time comprehending code, and a meaningful fraction of the code they're comprehending does nothing, then some very real slice of your engineering payroll is spent understanding, testing around, migrating, security-patching, and carefully stepping over functions that have not done one unit of work since before your last funding round.

And the situation trends one direction. Meir Lehman's laws of software evolution predicted it decades ago: used systems grow continually, and their complexity grows with them unless deliberate work pushes back. Code is added constantly; code is deleted rarely and nervously. The Gary population only ever ratchets up — and in the LLM era, where generating a new function costs approximately one sentence of typing, the hiring rate of future Garys has never been higher. GitClear's longitudinal analysis of hundreds of millions of changed lines found copy-paste-style duplication rising sharply alongside AI-assistant adoption: more near-identical functions entering codebases, which is tomorrow's dormancy in its larval stage.

Why nobody deletes Gary

If dead code is so costly, why does every team hoard it? Three honest reasons:

1. Fear of misdiagnosis. Without runtime data, "dead" is a guess. Maybe that function runs once a year, during the December billing close, and deleting it detonates a bomb with a six-month fuse. (This terror is legitimate — it's the subject of Part 18 of this series — but notice what it implies: teams keep dead code because they CANNOT TELL dead from rarely-alive. That's an instrumentation failure wearing a caution costume.)
2. Zero credit. Deleting code produces no demo, no feature announcement, no metric anyone celebrates. The incentive gradient points entirely toward addition.
3. The grep problem. Static analysis can find some unreachable code, but dynamic languages, reflection, dependency injection and "it's referenced in a config file somewhere" defeat it constantly. The only truthful witness to whether code runs is production itself.

That last point is the crux. Attendance can't be inferred from the org chart; you have to actually take attendance. (Taking attendance — every function's call count, continuously, with the dormant ones flagged in a state we literally named Snoozing — is one of the first things CodeNSM shows a new project, and the first census is reliably the moment someone says "wait, THAT'S not used?")

A thought experiment for your next engineering all-hands

Try this one on your team:

1. Imagine we printed the entire codebase on paper and pinned it to the office wall. Every function, every file.
2. Now imagine we highlighted, in green, every function that has executed at least once in the last 90 days.
3. Question one: what fraction of the wall is green? Have everyone write down a number privately.
4. Question two: for the un-highlighted part — who is maintaining it, and what did that cost last quarter?

The spread of answers to question one is the interesting part. If your senior engineers' estimates range from 50% to 95% (they will), then your organization does not know the answer, which means every migration, every framework upgrade, every "how long to add SSO?" estimate silently includes an unknown surcharge for walking Gary's desk through the change too.

The offboarding your codebase never had

Companies are ruthless about human headcount because human headcount is visible: a name, a salary line, a manager who must justify the role. Code headcount has no such review. No function has ever been asked to justify its continued existence in a calibration meeting. The result is exactly what you'd predict from the incentives: a workforce that only ever grows, where the working majority carries a silent, salaried minority, and where the payroll — paid in comprehension-hours, the most expensive currency you have — climbs a little every quarter.

Stripe's Developer Coefficient report put the industry's maintenance-and-bad-code burden at over 40% of developer time. Some of that 40% is honest toil on living systems. But some quiet slice of it is pure Gary: effort spent preserving, understanding, and stepping around code that retired years ago and never told anyone.

You wouldn't run human payroll without attendance. Your other workforce deserves the same rigor — if only so that, finally, someone can walk over to that desk in the hallway and ask the question nobody's asked in three years:

"Gary... what is it you actually do here?"