Тщательное продумывание проблемы / дизайна улучшит окончательный код. Но если вы не потратите месяцы на дизайн, когда будете писать код, вы обнаружите обнаруженные недостатки в дизайне, новые функции, о которых вы не думали, или взаимодействия, которые вы не ожидали. И в большинстве программных проектов цели будут перемещаться (клиент захочет что-то немного другое, или у вас будет отличная идея на полпути и т. Д.).
Водопад склонен к тому, чтобы весь проект был завершен заранее, прежде чем вы поймете, как будет работать код - это негибко и приводит к недостаткам дизайна, которые обнаруживаются слишком поздно, чтобы что-то с ними делать. Обычно даже в подходе с водопадом я бы предложил создать прототип, в котором задачи кодирования с высоким риском фактически реализуются на этапе проектирования в достаточно большой степени, чтобы подтвердить, что они могут быть выполнены и будут работать по желанию.
Agile подходы предполагают, что вы должны только проектировать столько, сколько вам нужно, чтобы начать, а затем делать немного больше дизайна позже, когда вы обнаружите, что это необходимо. Это смешивает кодирование с дизайном и обеспечивает гораздо более гибкий подход. Тем не менее, это часто неверно истолковывается как означающее, что «никакой дизайн» не выполнен, или о больших частях проекта не думают, пока не станет слишком поздно - это не должно иметь место. Вы должны спроектировать общую структуру настолько, чтобы вы понимали, как действовать, и чтобы мелкие части дизайна, которые вы не указали, были достаточно простыми, чтобы вы знали, что сможете разработать их позже, не ставя под угрозу конечный продукт.
Итак, каким бы путем вы ни пошли, вам нужно планировать достаточно хорошо, чтобы вы знали, куда идете, быть достаточно гибкими, чтобы менять направление, когда это необходимо, но во время процесса написать некоторый код (прототип или окончательный код), чтобы помочь ваш дизайн. И будьте готовы к рефакторингу и переписыванию частей программы, если они окажутся неадекватными.