Defining, Measuring, and Managing Technical Debt

Нужно операционное, а не абстрактное определение technical debt

Google собрал определение через интервью и реальные ответы инженеров: что именно мешает работе и какие способы смягчения реально применяются в командах.

Опросы нужны, но сами по себе не решают задачу измерения

Они дают полезный контекст, но при частичном охвате выборки и квартальном ритме становятся запаздывающим индикатором и хуже подходят для раннего обнаружения проблем.

Технический долг оценивается относительно целевого состояния

Инженеры сравнивают текущую систему с ожидаемым будущим дизайном, поэтому только исторические метрики состояния кода не объясняют картину полностью.

Управление долгом работает как регулярный управленческий цикл

Эффект появляется, когда команды регулярно обсуждают осознанность долговых решений, объем инвестиций в погашение и качество самого процесса управления.

Проблема статистической мощности

В quarterly survey участвовала примерно треть приглашенных инженеров, а приглашали только треть организации. Для многих команд это давало слишком широкие доверительные интервалы.

Lagging indicator вместо leading

Опрос фиксирует технический долг тогда, когда он уже заметно мешает работе. Для профилактики этого недостаточно: нужны сигналы, срабатывающие раньше.

Прокси-метрики плохо обобщаются

Авторы протестировали 117 метрик по трем типам технического долга, но даже модели вроде linear regression и random forest не дали стабильного качества предсказаний.

Без контекста будущего состояния измерение неполное

Если команда стратегически мигрирует стек или архитектуру, текущая реализация может считаться долгом даже при нормальных локальных метриках.