Оценивать риски смысла нет, потому что если не делать гигиену полости рта, то зубы точно выпадут. Иными словами, TTM точно упадёт, а TCO точно будет расти.

Чтобы спасти зубы есть рецепт - делать гигиену полости рта.

Чтобы спасти TTM и TCO тоже есть рецепт - заниматься дизайном, рефакторингом и документированием.

хмм. а что тогда дадут задачи по рефакторингу? вот у нас есть какой-то кусок кода с запашком, недостаточно оптимален, но проблем с быстродействием не вызывает.

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

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

и тут возникают два вопроса:
- кто создает задачи на рефакторинг?
- была ли первая задача бесполезной? ведь по факту потратили время впустую

или проект вдруг завтра вообще пойдет на помойку

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

Вот тут нужно чётко понимать, где границы MVP и иметь договорённости с бизнесом, когда отправлять MVP в корзину и начинать работать по-взрослому.

То есть бизнес должен отдавать себе отчёт, когда разработка идёт в корзину, а когда на перспективу.

Непростой вопрос. Термин "редизайн" у нас не прижился, поэтому говорим о рефакторинге в результате дизайна (итеративного), а не только для устранения тех долга и улучшения читаемости (сопровождаемости)

что-то вроде правила бойскаута, получается?

Не знаю такого правила

это от Роберта Мартина пошло, из книги "Чистый код"

-Правило бойскаута: Оставь место стоянки чище, чем оно было до тебя. Это легко перекладывается и на программирование. Видишь грязный код? Сделай его чище, пока решаешь свою задачу. Не стоит увлекаться этим и если грязный код очень грязный, то стоит выделить отдельную задачу и время для его очистки.

может я не так понял, но вроде как очень похоже

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

На самом деле, это целая наука - выбрать нужное время и место для рефакторинга. Стоит несколько раз ошибиться, и этот термин будет надолго дискредитирован в глазах менеджмента. Эта тема хорошо раскрывается в:
1. https://martinfowler.com/bliki/Yagni.html
2. https://martinfowler.com/bliki/TechnicalDebt.html
3. “Refactoring: Improving the Design of Existing Code” by Martin Fowler - у него целая глава на тему "WHEN SHOULD WE REFACTOR?", желательно смотреть во 2-м издании, там этот вопрос освещен немного лучше.
3. “Extreme Programming Explained” 1st edition by Kent Beck, главы "Chapter 3. Economics of Software Development" и "Chapter 20. Retrofitting XP".

буквально только что смотрел описание, отзывы рефакторинга Фаулера)

за ссылки большое спасибо, с удовольствием посмотрю, но уже днём, наверно

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

С одним исключением - MVP

Почему так? Иначе утилизация победит

так ведь она победит, только если совсем не уделять время

Да в какой-то момент очередной рефакторинг хер продашь, потому что будет что-то припирать, сроки, бюджет и т.д.

За это время проект превратится в говно.

Менеджеров постоянно что-то припирает.

Голдрат в каком-то смысле об этом тоже говорит.

но ведь бизнес сам должен понимать, на какие риски он идет, разве нет?