Your "Backup" Engineer Hasn't Touched That Code in Two Years
By Fahad Ijaz · · 6 min read
Ask an engineering leader about their bus factor and you'll usually get a reassuring answer: 'Two or three people know that area.' It sounds safe. It's usually fiction. Because when you actually look at who has touched that code recently — not ever, recently — the list collapses to one name, and the 'backups' turn out to be people who last opened those files during a project that wrapped eighteen months ago.
Bus Factor Is a Blast Radius, Not a Count
The useful question isn't 'how many people have committed here?' It's 'if this specific person is unavailable tomorrow, what knowledge goes dark?' That reframes bus factor from a single org-wide number into a per-person blast radius: the set of areas where losing one individual would leave real work orphaned. Some people have a tiny radius. A few have an alarming one. You want to know which is which before a two-week notice, not after.
Old Commits Are Not Coverage
The most important correction is about time. A contributor who wrote half of a module three years ago and hasn't returned since is not a living backup — the code has moved, the context has faded, and in practice they'd be reading it nearly as cold as anyone else. Real coverage has to be recent. Treating knowledge as something that decays — active, recent, aging, then effectively stale — is what separates a comforting org chart from an honest risk map. A co-owner who's gone quiet for over a year should count as a warning, not as reassurance.
Measure It at the Right Altitude
File-by-file blame is too noisy to reason about and too coarse when it's just a headcount. The right altitude is the area — the parts of the system a person actually owns in practice — scored by how much of that area's knowledge concentrates in them and how recently they've been in it. That gives you something you can act on: not 'file X has one author,' but 'this whole area depends on one person, and nobody active is close behind.'
What You Do With It
A real blast-radius map turns knowledge risk into a to-do list. The high-radius, single-owner, aging areas are your pairing assignments, your documentation priorities, and your next code-review rotations — chosen deliberately instead of discovered during an outage. It also changes hiring and retention conversations: you can point to exactly which departures would hurt and why, rather than treating everyone as equally replaceable or equally irreplaceable.
The Takeaway
The scary version of bus factor was never the number of people who ever touched the code. It's the number who still could, today, without a ramp-up. Measure coverage with a clock running, look at it per person and per area, and the risks you've been carrying without naming finally have names — while you still have time to do something about them.