Трущёбы

Трущобы - это убогие, беспорядочные бедные кварталы. Пожалуй, все согласятся, что в них нет ничего хорошего, но существуют объективные причины, способствующие появлению трущоб. С чем они связаны?

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

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

Слишком много программных систем на сегодняшний день, с архитектурной точки зрения, напоминают такие трущобы. Вложения в инструменты и инфраструктуру чаще всего недостаточны. Инструменты обычно примитивны, а инфраструктура, например библиотеки и среда, недостаточно развиты. Отдельные части системы развиваются без какой-либо проверки, а отсутствие инфраструктуры и архитектуры позволяет проблемам в одной части системы ухудшаться и заражать прилегающие части системы. Конечные сроки завершения системы маячат на горизонте, поэтому кажется невозможным добиться архитектурной изящности.

Когда приближается завершение разработки системы, с ней впервые могут начать работать фактические пользователи. Этот опыт может вдохновить на изменения формата данных и пользовательского интерфейса, что снова отрицательно сказывается на архитектурных решениях, хотя все думали, что с архитектурой все улажено. Также, как отмечает Brooks [1995], так как программное обеспечение такое гибкое, оно часто несет на себе бремя архитектурных компромиссов на поздней стадии цикла развития документации программного обеспечения/аппаратных средств, именно из-за этой гибкости.

Этот феномен не уникален и встречается не только в ПО. Stewart Brand [1994] заметил, что период до того, как здание будет заселено первыми жильцами, является самым напряженным как для архитекторов, так и для клиентов. Деньги кончаются, а осталось доделать именно те части здания, с которыми жильцы будут чаще всего сталкиваться. В этот период становится очевидным, что некоторые пункты из списка желаемых вещей не получается выполнить, а различные экзотические эксперименты не будут работать. Поэтому выполнение самого важного на данный момент становится компромиссным решением.

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

Затраты: Архитектура - это долгосрочная инвестиция. Люди, которые оплачивают счета, обычно пренебрегают этим, только если они сразу не получат осязаемую выгоду, например, списание налогов; или если не будет дополнительной прибыли или больше времени. Однако такое случается редко. Чаще всего клиент хочет получить продукт, который уже завтра будет на него работать. Как правило, люди, которые контролируют и управляют процессом разработки просто не рассматривают архитектуру, как неотложную проблему. Если программисты знают, что их усилия и профессионализм останутся без внимания, а менеджеры все равно не хотят платить за хорошую работу, рождается порочный круг.

Навыки: Ральф Джонсон заметил, что неизбежно «в среднем, в средних компаниях будут работать средние сотрудники». Одна из причин популярности и успеха такого подхода, как большой комок грязи может заключаться в том, что этот подход не требует гиперпродуктивного архитектора-виртуоза.

Организация: при работе над масштабными проектами, вопросы культуры, процесса, организационные моменты и проблема распределения ресурсов могут преобладать над техническими аспектами, такими как инструменты, языки и архитектура.

Программист может полагать, что погружение в это болото - большой вопрос “качества жизни”, однако комфорт программиста - это далеко не единственная забота менеджера, и она может противоречить многим другим проблемам. Менеджер может воспринимать качественную архитектуру и код, как излишество, которое лишь косвенно влияет на конечный финансовый результат.

Следовательно, акцент сначала делается на свойствах и функциональных возможностях, затем на архитектуре и эффективности.

Описанная ситуация напоминает аргументы Габриэля (Gabriel) «Чем хуже, тем лучше» [Gabriel, 1991]. Brand, [1994] заметил, что здания с большим пространством, украшенные обычными колоннами обладают парадоксальным эффектом, а именно они способствуют инновационному повторному использованию пространства как раз, потому что колонны ограничивают созданное пространство. Грандиозные полёты архитектурной мысли были невозможны, что сокращало количество возможных альтернатив.