Как известно, есть бизнес-задачи а есть задачи технические.
Бизнес хочет скорейшего решения и оценивает работу по количеству сделанных бизнес задач. Но тут есть нюанс — что можно худо-бедно решить эти задачи быстрее за счет понижения качества кода, как бы оставить на потом.
И как обычно назревает — что эти оставленные косяки начинают тормозить процесс вплоть до полной его остановки.
Представим что вы вошли в проект и там много таких "оставленных на потом" вещей, которые не позволяют повысить качество. К примеру, для серверных ошибок нет типизации и в каждом месте стоит своя лесенка из условий, чтобы понять что произошло (или вообще некорректное поведение, основанное на том, какие ошибки наиболее часто возникают, а не на всех возможных вариантах — без проверки реальной ситуации). Или нет юнит-тестов как таковых и архитектура не сильно заточена под их простое добавление. Вы говорите — давайте все это в одно место вынесем и приведем в порядок — а вам — та не, сейчас не время — потом этим займемся, когда зарелизим.
И тут как-то понимаешь, что работа в бардаке вряд ли поможет быстрее сделать релиз.
Вроде да — вот прямо сейчас быстрее эту задачу сделать, не работая над системой классификации исключений — оставить как есть. Но будет работать лишь для части случаев. Потом тебе дают баг — вот для этого случая не корректно отработало — и опять нужно вернуться с тому, что откладывалось или добавить очередную лесенку именно для этого случая.
Что вы делаете в таких случаях? Идете на поводу или упираетесь и приводите сначала в порядок базу?
С одной стороны если начать приводить в порядок базу — то тебе предьявят что ты вместо решения бизнес-задач фигней страдаешь.
С другой стороны если базу не привести в порядок — то предьявят что ты все делаешь медленно, все ломается, все не стабильно работает.
