Цифровые Мысли

побазарим?
тут либо терминологическое недопонимание либо принципиальное

1. вот у вас небольшой проект в начальной стадии
вы подумали над архитектурой в общих чертах
не заглянули в книгу "как проектиировать большой и малый тдыщ"
а подумали - творческий процесс, угу?
вы не трех-головый и поэтому с этой задачей в одиночку бороться не комильфо
если команда небольшая то весьма вероятно что вам в этом будут помогать толковые разработчики
(назовите их lead'ами или еще хрен знает как
но в небольшой команде это будут какие-то разработчики
и заниматься они будут творчеством)

2. допустим у вас большая команда и есть архитектор (look how lucky you are!)
ну сваяли вы архитектуру в общих чертах - пора бы передавать отдельные модули на разработку конкретным людям
способов реализовать тот или иной модуль бывает несколько (в начале проекта-то)
а у вас быдлокодеры и у них вопросы. много.
они заглянули в "большой и малый тдыщ" но в глоссарии нет пункта "стандартные подходы для инвентаризации банков телефонных номеров"
и архитектурное чутье молчит (по определению)
значит или не дай бог сдалаем как-нибудь побыстрее
или будем писать вопросы. много. без предложений и ярких идей.
можно написать этим балбесам уйму документов (по времени иногода сравнимо с реализацией самому)
и убить кучу своего времени и времени тольковых разработчиков (lead'ов)
и это работает (хотя опыт показывает что за всем усладить невозможно)
но мне не кажется такой подход оптимальным
наиболее сильно минусы такой команды:
- трудности в начале проекта когда нет отточеной строевой
- тонна сверху станартного набора документов для реализации
- невозможность оперативно решать проблемы особенно если команда распределенная
- проблемы когда ключевые люди уходят в отпуск
- наконец это очень скучно. нет правда, в этом нет драйва а значит нет мотивации а это источник новых проблем

p.s.
проблемы творческого программирования озвученные вами
("километры творческого говнокода и полный раздрай вплоть до мордобития" и проч)
ни сколько не доказывают недееспособность этого подхода
скорее рождают вопросы по организации работы
- есть design review, code review и много других полезных вещей
которые призваны идентифицировать подобные проблемы заранее