Defining, Measuring and Managing Technical Debt

Alexander Polomodov and Dmitry Gaevsky discuss Google's paper on defining, measuring, and managing technical debt. Ward Cunningham's metaphor leads into doubts about whether the term is universal. The hosts test the paper's structure against platform-engineering practice.

Google approached the topic through developer productivity: engineers saw an obstacle but used one label for different things. Researchers combined interviews and quarterly surveys with tool logs, produced ten categories, and selected several for testing. The taxonomy and measurements depended on organizational culture and scale.

Dmitry replaces abstract debt with a choice among options under business, time, and technology constraints. One label mixes necessary deferred work with harmless code imperfections. The first questions are whether the work is needed, what consequence it prevents, and which alternative was sacrificed earlier.

Categories become useful when they turn into observable work types. Teams can compare products and stacks, prioritize shared tooling, and remove recurring obstacles. Yet value is hard to prove without a baseline. Technical and product change should share one decision process instead of being split into a separate debt backlog.