S>Самое страшное — когда какой-то мелкий баг, почти не значительный. Но чтобы его устранить — будет потрачено очень очень много времени. И глубинная причина — что все изначально писалось с целью как можно скорее показать результат выполнения текущей задачи и в перспективе уволиться — без рефакторинга и пр. Т.е. на первых порах это работает, потом начинается хаос в системе.

S>Правильное решение — провести рефакторинг, но т.к. это слово не понятное и как бы не имеет измеряемого результата для бизнеса — его не проводят.

это фигня
рефакторинг и техдолг — устоявшиеся в индустрии понятия
я однажды даже заставил техдира настоять перед заказчиком на стабилизации продукта после рефакторинга


чего не люблю на работе — это когда просят сделать "как было", но с модификациями
"как было" — перезрело для рефакторинга или даже реинжиниринга
но никто не может сказать словами, с пользовательской точки зрения как было
(уволились или забыто давно)

в итоге приходится либо делать модификацию в том что есть, распознав концепцию решения
либо распознать из кода семантику того, что же он делал, после чего зарефакторить

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

этот отчёт был сдан в рамках внутрикорпоративной приёмки, поэтому начальник замял мой вердикт
но спустя пару месяцев я услышал, что в соседнем отделе аналитики пришли таки к выводу что он считает не так