Есть у меня идея, которую я называю “теория о несжимаемой сложности”. Звучит так:

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

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

Сюда же относятся микросервисы. Полагаю, сегодня очевидно всем: фрагментация сервисов не упрощает систему. Когда сервис А идет в сервис B, а тот в C и D, сложность устремляется в потолок. Нужен тулинг, чтобы отслеживать цепочки вызовов, находить сетевые задержки, воевать с сериализацией данных, находить тех, кто кого-то ди-доссит, разворачивать сложный CI. Где здесь упрощение?

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

Под теорию несжимаемой сложности подходит вся веб-разработка. В нулевые года мы писали на смеси HTML и неудачного языка – PHP. Сегодня мы пишем на смеси HTML и другого неудачного языка – JavaScript. Чтобы “упростить” процесс, Микрософт выкатила свой TypeScript, который тоже нужно учить, понимать, местами – бороться. За двадцать лет, после вложения адских денег и миллинов человеко-часов, мы в лучшем случае остались при своих.

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

Однако сложность никуда не делась: ее перекинули на учителей и детей. Должны быть компьютеры с интернетом. У ребенка должен быть телефон, почта, учетка на Госуслугах. Пароль от нее должен быть не менее 8 символов с решетками и долларами, при этом ребенок обязан помнить его, чтобы ввести на чужой машине. Спрашиввается: что именно этим упростили?

Я давно заметил то, что выражено в начале статьи: многие улучшения на самом деле не снижают сложность, а выдавливают ее на другой участок, перекладывают на чужие плечи. Дробим микросервисы – растет сложность их взаимодействия. Выносим логику на фронтенд – там ничего не работает, а мы даже не знаем об этом. Обложились технологиями – тонем в их несогласованности. Цифровизировали образование – втянули детей в цифровое болото, хотя должны были оттягивать этот момент. И так далее.

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

А теперь у нас эйай, и все сказанное умножается на бесконечность. Теперь на каждом участке что-то отчаянно “упрощают”: генерят код, тесты, скрипты, документацию. Обещают десятикратное повышение всего и вся, но пока что видно обратное. Если и раньше было трудно обуздать сложность, то теперь она льется через край.