Как не переборщить с желанием все спроектировать прежде чем писать код?
>не нравится как он написан
пффф а ты что думал,  в сказку попал? тебе и не должно нравиться, это для бизнеса где-то на 25 месте находится. 
-----
чесно говоря я вообще не слышал чтоб реально на практике УМЛ использовали, для проектирования (хотя тема когда-то и была на хайпе). 
Ну да на черновиках набрасывают общие идеи, сам код также может быть тем черновиком для идей, но это всего-лишь черновик. 
=======
>"Давай декомпозируем на задачи и начнем делать. По ходу реализации разберемся"
очень грамотный, взвешенный подход. Основная проблема не опытных людей, попытка сразу выдать идеальный результат в вакууме, люди которые поопытнее знают что это сделать не возможно, а попытка идеальной проектировки приведет только к переусложнению и ухудшит разработку и вместо того чтоб гибко подгонять решение под постепенные уточнения, вы будете стремится все подогнать под рамки какой-то первой "идеальной" идеи реализации, на основе первого восприятия задачи (которое часто ошибочно).
2 часа на проектирование, опционально 2 часа на обсуждение, а дальше делать.
Вопросы и уточнения в любом случае появятся в процессе.
Декомпозировать - это хорошо. Вопрос лишь в том, КАК декомпозировать. Это по сути и есть общая архитектура, которую стоит продумать заранее.