Применяемый, в быстро развивающемся Internet, такой неоднозначный подход, как Rapid Application Development (RAD), еще больше обостряет ситуацию. Проекты часто разрабатываются на скорую руку - лишь бы что-то быстро показать инвесторам, а затем уже пересматривается архитектура, приглашаются профессиональные дизайнеры. Но эти дизайнеры совершенно бессильны что-либо исправить в той кошмарной смеси HTML, SQL и VB/J/PerlScript которая, в общем-то, разрабатывалась как прототип, и была, почему-то, принята за конечный продукт (по горячему желанию руководства), в котором надо всего лишь "немного улучшить дизайн".
Вышеописанное несколько напоминает распространенную ситуацию с популярными средствами RAD в области разработки обычных Standalone-приложений. Такими как Delphi, C++Builder, Centura Team Developer, VisualBasic, и т.д. Когда код бизнес-логики оказывается "размазанным" по различным обработчикам элементов пользовательского интерфейса. Навсегда связывая проект с имеющейся технологией и архитектурой и затрудняя поддержку и расширение кода. Масштабирование(т.е., например, вынесение бизнес-логики в объекты 2nd tier - COM,CORBA,EJB), фактически, становится невыполнимым, поскольку код бизнес-логики придется, в буквальном смысле, "соскабливать" с различных ComboBoxes, TextFields, Buttons, и т.п.
Таким "размазыванием" страдают и современные разработки на ASP. С другой стороны, представляется вполне возможным избежать подобной ситуации. Просто осознавая с самого начала возможные неприятности в будущем, и закладывая в проект дополнительные степени свободы. Например, всегда хорошо иметь, про запас, возможность быстро сменить инфраструктуру Web-приложения - т.е., например, перейти с ASP на JSP или PHP, без переписывания основного кода. И эта возможность - вполне реальный эффект (причем м.б. даже побочный) хорошей организации проекта.