Skip to content
back to the episode
Episode summary2024Fellow

Defining, Measuring and Managing Technical Debt

Alexander Polomodov and Dmitry Gaevsky discuss technical debt in terms of the cost of future work. The conversation extends beyond code quality: complex architecture, missing tests, opaque processes, and lost knowledge can also impede development. Its central question is how to make these costs visible and agree with product colleagues on which problems deserve attention first.

Research Insights Made Simple3 min read

This summary is shorter than the original material; examples and assessments reflect the participants’ experience and views.

The main thread of the material
01

Distinguish a deliberate trade-off from an accumulated problem

The debt metaphor connects a quick decision today with the cost of change tomorrow. A shortcut can be a deliberate way to test a business hypothesis, or it can arise from haste and insufficient control. The conversation distinguishes these situations: the existence of a temporary solution does not explain why it was chosen or when it should be reconsidered. Management decisions need that context.

The speakers discuss code, architecture, testing, documentation, process, and social debt. The last category concerns how well the team understands the system and can transfer knowledge. Working code does not remove a maintenance problem when personnel change. Documentation, transparent decisions, and inter-team dependencies therefore belong in the discussion alongside the application's technical structure.

02

Combine measurement with an explanation of the difficulty

The conversation does not propose a universal metric for every kind of debt. A count of TODO comments may prompt investigation but does not itself establish a problem's cost. Static analysis reveals some code properties, while interviews and surveys help identify where people lose time and why. Results need to be interpreted against the work of the particular team.

The discussion combines quantitative observations with qualitative evidence: code analysis, reviews, surveys, and developers' accounts of their experience. Including managers helps connect local difficulties to organizational consequences. Repeated manual work may indicate missing automation and recurring costs. That signal still requires evaluating frequency, scale, and the value of a fix rather than immediately classifying every manual operation as debt.

03

Give repayment an owner and a place in product planning

The proposed sequence is to identify a problem, categorize it, assess it, prioritize it, and address it. Product participation matters because technical improvements compete with other work for time. The speakers suggest explaining their value through stability, future development speed, and risk. This makes the discussion more concrete than a request for unspecified quality improvements.

A shared issue tracker, a dedicated board, and regular review can make debt visible. Work needs an owner and a clear completion criterion. Adding an item to a list does not solve it: agreed priority and execution are still necessary. The closing argument treats repayment as an investment and encourages open discussion between engineers and leaders while balancing current product capabilities with the ability to develop the system further.

Takeaways

What to take away

  1. 01Assess technical debt through future costs and the reasons behind the original decision.
  2. 02Interpret technical measures alongside people's experience and the team's context.
  3. 03Repayment needs ownership, an agreed priority, and a clear completion criterion.

Sources