Это называется энтропийный дрейф или эффект нарастающей сложности. Работает на всех уровнях - от кода до бюрократии.

Причины:

1. Добавление легче удаления. Когда ты добавляешь новую функцию или правило, ты не затрагиваешь существующую систему. Просто наращиваешь сверху. Удаление же требует понять все связи и зависимости. Нужно убедиться что удаление одного элемента не сломает десять других. Это анализ, тестирование, риски.

2. Страх потери. Люди боятся выбросить что то "на всякий случай". Вдруг этот костыль в коде кому то нужен? Вдруг это правило защищает от редкого но критичного бага? Проще оставить как есть и добавить новый костыль рядом.

3. Отсутствие глобального видения. Каждый разработчик или менеджер видит свой участок. Он добавляет решение для своей задачи, не думая как это повлияет на систему в целом. Упрощение же требует понимания всей архитектуры.

4. Институциональная инерция. Сложные системы обрастают людьми которые заинтересованы в их сложности. Бюрократ получает зарплату за обработку форм - зачем ему упрощать процесс? Консультант зарабатывает на обучении сложному софту - зачем делать его простым?

5. Цена ошибки. Усложнение безопасно - в худшем случае ты добавил лишнее. Упрощение рискованно - можешь удалить важное и все сломать. Поэтому люди выбирают безопасный путь.

Правило: упрощение требует смелости, экспертизы и власти. Усложнение доступно всем.

Вспомнилась цитата Блеза Паскаля из 17 века: "Я написал длинное письмо, потому что у меня не было времени написать короткое".

Короткий текст требует многократной редактуры, выбрасывания лишнего, поиска точных слов. Длинный - просто выливаешь все что в голове.

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

Работаю в энтерпрайзе 12 лет. Видел как системы превращаются в монстров.

Основная причина - никто не отвечает за упрощение. За добавление фич отвечают продакты, за исправление багов - девелоперы, за документацию - технические писатели. А за рефакторинг и упрощение? Никто.

Рефакторинг не приносит видимой пользы бизнесу. Менеджеру проще показать "добавили 10 новых фич" чем "переписали старый модуль и теперь он проще". Поэтому упрощение всегда в конце приоритетов.

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

Это эволюционная особенность мозга. Мы запрограммированы на накопление информации и опыта. Выбросить что то из памяти сложнее чем запомнить новое.

Плюс когнитивная нагрузка. Чтобы упростить, нужно держать в голове всю картину целиком и видеть что можно безболезненно удалить. Это требует огромной ментальной энергии. Добавить новый элемент - локальная задача, не требует глобального анализа.

Поэтому люди склонны наращивать сложность а не сокращать ее. Это путь наименьшего сопротивления.

Еще один момент - эго. Разработчик гордится тем что написал сложную систему. Это демонстрация мастерства.

Упрощение же выглядит как признание "я накосячил, надо переделывать". Никто не хочет признавать ошибки. Проще продолжать усложнять и делать вид что так и задумано.

И да, сложность создает ощущение незаменимости. Если только ты понимаешь как работает этот монстр - ты ценный кадр. Упростишь - любой junior разберется, и ты потеряешь статус.

Сталкивался с этим при рефакторинге легаси кода. Удалить 1000 строк страшнее чем добавить 2000.

Потому что добавление - это контролируемый процесс. Ты знаешь что делаешь. Удаление - это риск. Можешь сломать что то что работало 10 лет и никто уже не помнит зачем оно нужно.

Нужны очень хорошие тесты и смелость чтобы резать. Обычно этого нет.

просто все ленивые) проще накидать костылей чем думать головой и делать нормально

О да, у нас на проекте код настолько зарос что его проще переписать с нуля чем разобраться что там происходит. Но менеджмент не дает ресурсы на рефакторинг потому что "работает же, не трогай".