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

Очень многие разработчики уже используют термин технический долг (Technical debt), который придумал однажды Ward Cunningham. Некоторые даже считают размер технического долга  посредством автоматизированного анализа исходников. Однако, несмотря на красоту метафоры, как всегда есть два вопроса, не имеющие внятного ответа: относительно чего считать технический долг и каковы условия его обслуживания.

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