Крах сложного программного обеспечения Перевод

В 1988 году антрополог Джозеф Тейнтер опубликовал книгу под названием «Крах сложных сообществ» . В нем он описал взлет и падение великих цивилизаций, таких как римляне, майя и чакоанцы. Его цель состояла в том, чтобы ответить на вопрос, который мучил мыслителей на протяжении веков: почему рухнули такие могущественные общества?

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

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

Что меня в этом завораживает (помимо очевидных последствий для современной цивилизации), так это то, что Тейнтер мог писать о программном обеспечении.

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

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

Каким бы разочаровывающим это ни было для тех из нас, кто стремился бы написать такое программное обеспечение, которое было бы вечным и долговечным, вы должны признать, что эта система работает. При всей своей расточительности, неэффективности и чистой лживости («Старый код работает отлично!» «Нет, подождите, старый код ужасен!») эта модель поддерживала многие компании-разработчики программного обеспечения в течение последних нескольких десятилетий.

Но будет ли этот цикл продолжаться вечно? Я не уверен.

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

Требуется большая дисциплина, чтобы сопротивляться сложности, чтобы сказать «нет» новым коробкам и стрелкам. Сказать: «Нет, мы не решим эту проблему, потому что это просто создаст 10 новых проблем, о которых мы еще не догадывались». Или сказать: «Давайте сделаем гораздо более простой дизайн, даже если он кажется дилетантским, потому что, по крайней мере, мы можем его понять». Или просто сказать: «Давайте делать меньше, а не больше».

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

В конечном счете, я думаю, будет ли программное обеспечение следовать модели подъема и спада или более устойчивой модели, будет зависеть от экономического давления организации, производящей программное обеспечение. Компания-разработчик программного обеспечения, которая ценит рост любой ценой, подобно римлянам, жадно поглощающим все больше и больше Галлии, скорее всего, попадет в цикл «добавление сложности и крах». Софтверная компания с более скромными целями, которая имеет стабильную клиентскую базу и не сильно меняется со временем (существует ли такая штука?), будет больше похожа на скромное племя, которое следует за ежегодной миграцией антилопы и фокусируется на устойчивом развитии. проверенные временем техники. (Другой вопрос, закончат ли такие отряды, как несчастные галлы, захваченные Цезарем и его войсками.)

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

https://nolanlawson.com/2022/06/09/the-collapse-of-complex-software/