Что делать с аналитическим параличем?

Перфекционизм вместо работы — это прокрастинация. Лечится розгами по карману.

У вас нет опыта решения тех задач с которыми вы работаете, отсюда и непонимание как должно быть. Если так то либо развиваться наступая на грабли, либо нужно поработать с наставником в этом вопросе. Например устроиться в компанию на позицию Middle/Senior где вы будете пилить фичи, но при этом вас будут контролировать выше.

Мне подходит следующий подход.
1. Делай что бы работало.
2. Делай тесты
3. Оптимизируй.

Если задачу не возможно сделать в лоб «что бы работало», декомпозируй.

Муки творчества и сомнения — это нормально.

Топик озаглавлен тегом ПРОЕКТИРОВАНИЕ но вопрос все равно про имплементацию. Поэтому я бы хотел спросить — кто автор? Если речь идет об имплементации — то он разработчик.

А поэтому нужен тег языка разработки и текста программы. И дальше уже — по ситуации.

Автор вопроса — сверхчувствительная личность (СЧЛ) с вероятностью близкой к 100%. И это не относится ни к программированию, ни к проектированию. И это не диагноз «перфекционизм» в плане того что это нужно лечить, потому что вылечить это невозможно, так устроена нервная система СЧЛ. Другие личности не поймут, они будут делать первое попавшееся решение, просто потому что так устроена их нервная система.

Советы от НЕ-СЧЛ не подойдут СЧЛ.

Я сам СЧЛ, программист, геймдизайнер, поэтому советую — расширять кругозор дальше, но не в ущерб деланию реальных задач. Сомнения — это нормально.
И те, кто говорят что они от недостатка опыта — в этом правы, отчасти потому что когда есть опыт решения конкретной задачи — анализировать тут почти нечего, когда решение принято кем-то (из статьи \ из книги \ или наставником \ или вами в прошлом) о том как выполнять эти задачи. Но если встает новая задача — всегда будет недостаток опыта. Всегда будет анализ плюсов и минусов каждого из найденных вариантов, и выбирать придется. Зачастую это много-критериальная задача оптимизации — выбираете что самое главное, что вторичное, что не важное. Скажем если надо сделать супер оптимально иначе у других не запустится на устройстве — ставите в задаче приоритет оптимизации под это устройство. А если бюджет близок к бесконечности — это идеально было бы.

Однако в реале придется еще срезать сроки разработки, и бюджеты — и выбрать не самое оптимальное решение, а удовлетворяющее первоначальной задаче (из примера это запускающееся на конкертном устройстве, или допустим едящее не более X GB памяти при таком-то кол-ве юзеров онлайн если это сервер игры), остальные неважные оптмизации — отбрасываются, когда основное — выполнено.

Если как говорят другие приоритет — скорость разработки, а не оптимальность программы (оптимизации в рамках разумного надо нарабатывать по опыту), то анализировать почти нечего — сначала чтобы работало и без багов желательно, потом оптимизировать если останется время.

Если есть много времени на исследование задачи (в частности для себя, не в большой ущерб здоровью от переработок) — перебирайте вы ваши варианты, но за все придется платить: вам — здоровьем или недополученной прибылью, работодателю — деньгами если вы делаете не супер нужные отпимизации (если — подчеркну).

p.s. Если у автора вопрос в 1ю очередь про то что ВСЕ варианты содержат БАГ, значит нужно продолжать искать решения, это тоже нормально, и по ходу вариант вы найдете, когда переберете кучу вариантов и отдохнете (это тоже важно), а может — из статьи или книги, если задача конечно решаемая (и вы не исследуете новейшие научные задачи).

Не думай! Делай!
Делай пока не упрешься в тупик. Чем быстрее упрешься в тупик, тем быстрее найдешь выход.