Техническая красота решения

Техническая красота решения имеет чёткие бизнесовые показатели - скорость, стоимость поддержки, удовлетворённость команды. Когда программист говорит: "А давайте всё это Г перепишем заново, а то оно ужасно написано", подумайте, какой показатель от этого изменения "выстрелит":
- уменьшится время на борьбу с багами при выходе новых версий?
- увеличится time2market?
- уменьшится число критичных (когда бизнес-пользователь не может выполнить свою работу даже обходным путём) инцидентов?
Если нет или не можете посчитать, значит, эта красота мнимая. С другой стороны, у разработки появляется чёткий водораздел - хочешь переписать, покажи прирост по этим показателям. Научись их считать. Ну, и сами не будьте сквалыгами - задачи, которые нужно сделать, чтобы начать собирать метрики, должны попадать в спринт, а не лежать вечно на задворках бэклога. Если хотим снизить баги при выходе новых версий - давайте время на юнит и автотетсты.

Отдельно хочу рассказать про удовлетворённость команды. Это важная составляющая для эффективной работы. Никому не нравится ковыряться в плохо структурированном коде, нарисованном фиг знает когда фиг знает кем. Если понимаете, что люди киснут, ищите новые задачи, которые можно попробовать решить новыми технологиями. Да, иногда это может быть "больно" в плане появления "зоопарка технологий", но тут приходится выбирать из двух зол - либо забить на эффективное и интенсивное развитие продукта, либо потерпеть переходный период к целевой технологии, но таки расти и развиваться функционально. Выбор в каждом случае свой.