Начну издалека:
Технический долг - это тот долг, который мы занимаем у самих же себя. В контексте разработки (в том числе на BSl языке от 1С) - это время, которое мы не тратим сейчас, но которое потом зависнет над нами дамокловым мечом.

Disclamer: этой статьей я не хочу клеймить кого бы то ни было хорошим или плохим разработчиком; ТД - неизбежное зло процесса разработки, а в случае 1С – это неизбежная неизбежность. Как говорит наш технический директор:
Я обычно сторонник говорить, что сколько специалистов 1С, столько нетиповых конфигураций 1С, написанных с нуля...

Итак, технический долг - это время, которое нам понадобится, чтобы довести наш продукт до ума изнутри, то есть, исправить код. Различные ошибки, допущения, усложнения кода, вложенность и другие нюансы процесса разработки в итоге превращаются в трудодни, или иначе – ресурс,  который надо потратить на то, что, казалось бы, работает.

— Так если работает, зачем нам на это тратить время

Затем, что технический долг увеличивает стоимость владения и развития разрабатываемой системы; в процессе разработки увеличивается и сам технический долг, то есть еще сильнее растет стоимость владения и развития; а в какой-то определенный момент времени (Day "D") наступит коллапс системы, когда все усилия разработчиков будут тратиться только на поддержку системы, и о новом функционале придется забыть.

Еще раз, откуда вообще берется этот ваш "Технический долг"?

Про типичные ошибки, из которых как раз и складывается ТД, написано в этой статье: 


— Окей, допустим я сам себе задолжал, а оценить-то долг как? 

А вот сейчас надо выдохнуть и сказать спасибо самим себе, что живем в 21 веке, ибо есть люди и организации, которые разрабатывают системы по оценке того самого Технического Долга; системы эти есть и опенсоурсные, есть и закрытые разработки практически для всех языков программирования.

— Да какие системы, сейчас скажу разработчикам сесть и провести код-ревью, все поправят как надо!

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


Ну вот прочитал я это все, по ссылкам походил, все круто, Continuous Inspection во все края, а 1С-то тут как замешан? Как применимы эти вещи к 1С-разработке?

Речь как раз о том, что ваша команда разработчиков видит, кто и сколько привнес технического долга, то есть занял сам у себя в будущем времени на доработку; более того, это видит и менеджмент (если ему показать):

Для разработчиков 1С у нас есть, в некотором роде, уникальный продукт; подробнее здесь:

Вы нашли ответ?