[userpic]

... ↑

ex_sbobrovsk689 в посте Openmeta (оригинал в ЖЖ)

Окончание (постинг большой)
Потеря внимания, бдительности :) - основной источник проблем... Хотя, все же, если исходно спроектировано правильно, то потом ошибок почти не бывает. Обычно проблемы начинаются, когда заказчик просит доработать уже готовое ("вот тут чуть-чуть переделать"), а на самом деле это означает "есть дом в десять этажей, надо седьмой этаж чуть-чуть перестроить, на миллиметр стены расширить". Объяснить, что "размер" - миллиметр или метр, значения не играет, так как все равно придется сносить три вышестоящих этажа, а потом достраивать их заново, обычно очень сложно... Это же всего миллиметр! :) Заказчик мыслит совсем другими категориями.
И когда начинаешь делать "и нашим, и вашим", программа запутывается, и все...
Есть способы обхода этой потенциальной опасности, через изначальную ориентацию на максимальную гибкость архитектуры продукта и легкую возможность его любого расширения, но такая архитектура сама по себе стоит дорого в плане трудоемкости.
Тут у меня, конечно, переплетены в куче элементы модели программиста и методологические элементы проектирования, из программной инженерии. Описания методик типа экстремального программирования или CMM уже сами по себе, наверное, достаточно хорошо описывают модель программиста... Немного с другой точки зрения, конечно, не от состояний, а от организации процесса разработки. Но состояние ведь не уникально для программиста, любая интеллектуальная деятельность тут подойдет.
Кстати, для начинающих разработчиков актуально в основном нечто описанное выше, когда еще хорошего навыка кодирования нету. А для достаточно опытных (меня например :), состояние - главное, потому как производительность может различаться в сотни раз.
Интересно, что в литературной деятельности такого различия не бывает. Стивен Кинг пишет в день 5 кб текста, но даже 50 кб качественного (это важно) текста написать в день крайне сложно. Подготовка текстов - процесс более линейный, а в программировании все больше упирается в "угадать вначале правильную архитектуру системы".
Кстати, вполне возможно, что подойдет эта схема и при подготовке документации, технической, справочной (или даже художественной :). Только, чтобы этот процесс формализовать, надо пользоваться европейским стандартом на ведение документации S1000D - http://s1000d.org/
Он схож с программистскими концепциями, подразумевает составление документа из модулей, которые можно потом повторно использовать, и т. д.