The Value of Quantifying Technical Debt

Apr 2, 2016 | Productivity

Software teams do not tend to self-deploy optimally.

Fun fact: senior engineers spend the largest percentage of their time paying down technical debt. While this may seem intuitively true, talking with our users has revealed how uniform this is across the industry. In fact, “person who cleans up the most old code” tends to be a simple but accurate predictor of seniority for teams.

How most teams self-deploy when they're not thinking about it

Unfortunately this isn’t necessarily the best case scenario for the team, as it can lead to an undesirable state of affairs: slow but steady snowballing of technical debt.

Why does this happen?

  1. When a particularly nasty and long overdue refactor rears its ugly head, it often comes with lots of time pressure.
  2. The work is nearly always high risk, since modifying poorly architected bedrock code can cause the software to break in ways that are costly and embarrassing.

This creates a coordination problem not unlike the Prisoner’s Dilemma. The rational move here is almost always to let a Senior Engineer handle it. While this is a rational decision for every instance of overdue refactoring, or critical bug, it’s not actually the best outcome for the team as a whole, and this leads to the vicious cycle above. Chances are that your team does this too: the Senior-most engineers spend the most time refactoring legacy work.

A better way

The ideal scenario is a workflow where Senior Engineers are freed up to establish patterns for the rest of the team and each engineer becomes stronger and trains up to become a domain expert.

Spread out refactoring and strengthen the team

How to correct it

Measure it: The first step is seeing it. Without a feedback loop for how much work is being sunk into refactors on a weekly (or sprint-ly) basis, deciding to spread the load is impractical: there’s no way to measure success. 1

Be proactive: Incorporating this as a core metric into your team retrospectives and planning meetings, and encourage Junior engineers to take on important refactors before they come to a head and create time pressures in lieu of sticking to blue sky implementations & new features.

Look Forward: Set specific goals for upcoming development cycles and set up concrete goals for spreading the refactor load. Encourage new engineers to take ‘ownership’ of old areas of the codebase that have been neglected, which will help them build up their domain knowledge on the product.


 

  1. GitPrime quantifies engineering progress and can help with things like measuring the cost of paying down technical debt. 

 


 

Travis Kimmel

Travis Kimmel

Travis Kimmel is the CEO, co-founder of GitPrime, the leader in data-driven productivity reporting for software engineering teams. He is experienced in building high-performing teams, and empowering people to do their best work of their careers. Follow @traviskimmel on Twitter.

Get Engineering Impact: the weekly newsletter for managers of software teams

Keep current with trends in engineering leadership, productivity, culture, and scaling development teams.

how to use data to lead a successful software teams

A Data Driven Approach To Leading Software Teams

Learn how engineering leaders are using data to help their team increase productivity and become even more effective. We've analyzed over 40 Million commits to help you understand the important questions every software engineering manager needs to know.

Success! Please check your email for your download. You might also be interested in Engineering Impact: the Weekly Newsletter for Managers of Software Teams. Keep current with trends in engineering leadership, productivity, culture and scaling development teams.

Share This