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

Для сравнения - среди тысяч классов и десятков тысяч команд находящихся в стандартных тегах Java или .NET после некоторого ознакомления есть возможность, посредством дерева пакетов достичь необходимого места в общем случае максимально за пару минут, в большинстве случаев - за несколько секунд. Либо пользуясь тем же путём убедиться в том, что подходящей команды не существует. Если же это веб-система, которая подходящим образом не документирована и состоит из нескольких довольно случайным образом соединённых между собой частей, то на поиск и устранение одной, казалось бы, простой ошибки могут уйти дни. Хотя количество классов не превышает двадцати, а количество используемых команд не превышает двухсот (личный пример автора этого текста). Ещё хуже, если код вообще разумным образом не поделен ни на классы, ни на методы. В этом случае приложение состоящее даже из двух тысяч строк может показаться такой тайной, что проще будет для достижения того же результата переписать его заново, чем пытаться исправить уже существующее.

Написание кода заново не всегда может быть плохой мыслью и этого не стоит слишком сильно бояться. Надо только знать и быть уверенным в том, что в новом облик упростит дальнейшую разработку системы, и она будет значительно лучше управляема. Довольно часто такое переделывание может быть полезным в случае, когда приложение увеличивается в три, четыре раза по сравнению с предыдущей версией. Некоторые разработчики стараются избегать необходимости такого переделывания и стараются в самом начале создать проект с основательной структурой, где у каждой части кода есть своё место. Однако в этом случае результатом, как правило, бывает  например то, что в случае простого калькулятора создаётся дерево проекта с несколькими десятками каталогов и файлов, где содержимое специфичное для данного проекта находится лишь в нескольких файлах. Такой подход может быть удобным в случае фирм, занимающихся разработкой ПО, где есть чётко оформившаяся структура больших приложений и команда умеет быстро находить необходимые части кода. Если же это приложение, чья логика действий может быть описана парой заполненных программным кодом экранов, тогда своя прелесть есть в коротком решении - особенно, если впоследствии с эти кодом будут работать программисты с различными навыками и при помощи различных инструментов разработки. Компактный код порой удобнее даже в том случае, когда известно, что через пару лет придётся существенно переделывать систему, в связи изменением требований к ней и её увеличением.