Поделюсь недавней заметкой Дика Доуделла Rethinking Technical Debt, основная идея которой в том, что техдолг является скорее системной проблемой, а не просто изъяном, возникающем при неправильной доработке кода. И решаем мы эту проблему неверными способами

Forget the metaphor for a second. Technical debt isn’t just a design compromise or a lack of refactoring time. It’s a structural imbalance that arises when systems evolve without coherent patterns.

Причины дисбаланса по мнению автора:
- чрезмерное увлечение «лучшими практиками». Agile церемонии, TDD, микросервисы, CQRS, dependency injection etc. не заменяют архитектуру. Нельзя исправить ошибки декомпозиции: правильное определение границ между компонентами и взаимодействий, улучшая то, что находится внутри компонент
- иерархические вызовы вместо разработки bindable (связываемые, подключаемые) компонент
- … и отсутствие "модерации сообщений" (отдельный текст Дика The Magic of Message Moderation)
- шараханье от единственного монолита к хаосу случайных микросервисов вместо развертывания, называемого автором service nodes. Я бы назвал это осмысленным развертыванием
...

Ну а заканчивает автор замечанием, что это не фантазия или мечта, а реализуемая его командой реальность и что The architecture resists debt by design

Подытожу: идея переосмыслить источники технического долга мне точно нравится