A new day.  A new Quarter.  We know what that means; PI planning time.

This is it, you are up, you have been working on this presentation for the last week and a half. You start to talk about things like “change failure rate” and “mean time to recovery”.  You make an impassioned plea to retire some technical debt.

As you look around the room, you see it.  Eyes with more glaze than a jelly-filled doughnut.

You’ve lost and it isn’t even 10 A.M.

You lost not because you don’t know what you are talking about; not because you aren’t knowledgeable in your domain.  You lost because you brought a knife to a gun-fight.  You lost because you brought “feelings” to a “balance sheet”.

While your “feelings” are rooted in your lived experience in your day to day job, these feelings are not quantified on a balance sheet.  You stated an opinion, and the business said “Not this quarter, maybe next”.  The Sisyphus task continues.

The term “technical debt” has gone the way of “Kleenex”.  It has been used so much, it has lost its impact.  Just like Kleenex has come to represent anything you blow your nose with.  Technical Debt has come to represent anything an engineer doesn’t like.  It lacks in specificity.  It lacks data.  It lacks a quantifiable business impact.

And because of this, your argument for remediation of technical debt needs to change; or you will always be Sisyphus.

So lets reframe the conversation.  Lets stop talking about “things we don’t like” and start talking about risk.  So while your years of experience tells you that something isn’t right; make it quantifiable.  The best part here, is that all the data you need is already sitting inside your security perimeter; it’s buried in your Git repository.

So here is how we get there; how we stop talking about “technical debt” and start talking about these  things that you can measure:

  • Churn: How many times has a file or module been changed in the last six months? High churn indicates a volatile, unstable part of the system. This isn't an opinion; it's a number.
  •  
  • Bus Factor: How many unique developers have contributed to a module? A critical service that has only ever been touched by one person who is now on vacation is a measurable business risk.
  •  
  • Co-Change Correlation: When we change File A, what is the statistical probability that we will also have to change File B in the same commit? This isn't a "tight coupling" feeling; it's a percentage. It is the mathematical measure of your system's blast radius.

This new vocabulary leads to conversations that are built on quantifiable data.  Cold hard numbers that mean exactly what they mean.  You are now no longer talking about a gut feeling, or saying that “only Suzy makes those changes and that exposes us to risk”.  Now you can state, with verifiable data that: “The BillingService is in the 95th percentile for churn, has a bus factor of one, Suzy, and every time we touch it, there is a 78% chance we break the AuthenticationService. The next three features on your roadmap all require changes to the BillingService. This is not a technical problem; it is a direct, quantifiable risk to your Q3 revenue target.”

The conversation is no longer about the intangible “technical debt” (or Kleenex for that matter), but about the risk to delivery, he risk to a roadmap, the risk to revenues.

May the only glaze you see from here on out be on a doughnut.