Не совсем всегда. Во время программирования разработчик около 10% времени вводит символы с клавиатуры и около 90% он борется со сложностью и читает существующий код, и это еще оптимистичные цифры. Казалось бы, что чем чище код, тем лучше экономика. Но не всегда рефакторинг окупается. К нему также применим Принцип Парето. Есть код, который читается часто, и его рефакторинг быстро окупится и существенно улучшит экономику разработки. А есть такой код, который читается редко, и его рефакторинг не отразится на экономике разработки, но зато оттянет ресурсы от более приоритетных (и более монетизируемых) задач, что, кроме cost of repair, может повлечь за собой еще и ущерб упущенной выгоды ("cost of delay"). А есть такой код, который лучше вообще не трогать, и использовать Srangler Application или дублирование контекста. Ну и еще всегда будет образовываться prudent-inadvertent debt https://martinfowler.com/bliki/TechnicalDebtQuadrant.html , какой бы опытный разработчик не был, и как бы он не старался. Момент для устранения такого техдолга зависит от объема накопленных знаний, т.е. здесь время играет на руку.
В общем, по ссылкам все расписано.
А если мы говорим про reckless debt, то сколько времени на рефакторинг не выделяй, а качественных изменений это не принесет - у команды просто нет необходимых навыков.

я не согласен только с идеей отлельных задач на рефакторинг (хотя еще пару месяцев назад был сторонником такого подхода)

Не совсем всегда. Во время программирования разработчик около 10% времени вводит символы с клавиатуры и около 90% он борется со сложностью и читает существующий код, и это еще оптимистичные цифры. Казалось бы, что чем чище код, тем лучше экономика. Но не всегда рефакторинг окупается. К нему также применим Принцип Парето. Есть код, который читается часто, и его рефакторинг быстро окупится и существенно улучшит экономику разработки. А есть такой код, который читается редко, и его рефакторинг не отразится на экономике разработки, но зато оттянет ресурсы от более приоритетных (и более монетизируемых) задач, что, кроме cost of repair, может повлечь за собой еще и ущерб упущенной выгоды ("cost of delay"). А есть такой код, который лучше вообще не трогать, и использовать Srangler Application или дублирование контекста. Ну и еще всегда будет образовываться prudent-inadvertent debt https://martinfowler.com/bliki/TechnicalDebtQuadrant.html , какой бы опытный разработчик не был, и как бы он не старался. Момент для устранения такого техдолга зависит от объема накопленных знаний, т.е. здесь время играет на руку.
В общем, по ссылкам все расписано.
А если мы говорим про reckless debt, то сколько времени на рефакторинг не выделяй, а качественных изменений это не принесет - у команды просто нет необходимых навыков.

А с чем согласен?

Иван этим сообщением как раз описал проблему отдельных задач на рефакторинг

Напомню, мы вообще-то про дизайн говорили. А значит и рефакторинг вследствие редизайна.

да, но не всегда рефакторинг приводить к редизайну

Как решать?

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

И что?

то, что это все же немного разные вещи и надо их разграничивать. меня лично тема рефакторинга только интересовала, ибо больная тема

Вы это менеджерам будете рассказывать?

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

Иван этим сообщением как раз описал проблему отдельных задач на рефакторинг