Как известно, есть бизнес-задачи а есть задачи технические.

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

И как обычно назревает — что это оставленные косяки начинают тормозить процесс вплоть до полной его остановки.

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

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

Вроде да — вот прямо сейчас быстрее эту задачу сделать, не работая над системой классификации исключений — оставить как есть. Но будет работать лишь для части случаев. Потом тебе дают баг — вот для этого случая не корректно отработало — и опять нужно вернуться с тому, что откладывалось или добавить очередную лесенку именно для этого случая.

Что вы делаете в таких случаях? Идете на поводу или упираетесь и приводите сначала в порядок базу?

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

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

Как вы поступаете?

Как известно, есть бизнес-задачи а есть задачи технические.

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

И как обычно назревает — что это оставленные косяки начинают тормозить процесс вплоть до полной его остановки.

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

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

Вроде да — вот прямо сейчас быстрее эту задачу сделать, не работая над системой классификации исключений — оставить как есть. Но будет работать лишь для части случаев. Потом тебе дают баг — вот для этого случая не корректно отработало — и опять нужно вернуться с тому, что откладывалось или добавить очередную лесенку именно для этого случая.

Что вы делаете в таких случаях? Идете на поводу или упираетесь и приводите сначала в порядок базу?

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

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

Как вы поступаете?