На двери кабинета физики в институте, где я начинал свою трудовую деятельность, висела табличка: «Закрывайте, пожалуйста, дверь. Незакрытая дверь приводит к возрастанию энтропии Вселенной». Конечно, в данном случае термин «энтропия» был использован в житейском понимании — мера сложности, хаотичности или неопределённости системы. Незакрытая дверь — это, однозначно, непорядок, который приводит к общему увеличению энтропии. Народу табличка нравилась, никто не хотел причинять вред Вселенной. Призыв действовал — дверь обычно аккуратно закрывали.

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

В информатике есть известный замечательный принцип: «Garbage in, garbage out» (GIGO). Это правило очень хорошо подходит ко многим нашим системам. Если на вход поступает мусор, то на выходе будет очень сложно получить что-то, кроме того же мусора. Иногда многократно приумноженного.

Garbage in, garbage out

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

Песчинка за песчинкой

Бывает, что новое программное обеспечение разрабатывают на базе нечётких или фактически отсутствующих бизнес-процессов. Как ни парадоксально, но именно Билл Гейтс в книге «Дорога в будущее» метко высказался по этому поводу: «Первое правило для применения любой техники или технологии в бизнесе: автоматизация эффективной операции умножает её эффективность. А второе: автоматизация неэффективной операции умножает её неэффективность».

В этом случае мусор на вход поступает с самого начала — ещё до разработки системы. Достаточно одного-двух маленьких уродливых «бизнес-процессиков». Мы же знаем, что большое начинается с малого. Песчинка там, песчинка здесь — гора постепенно растёт.

Песчинка за песчинкой // Фото fabrikasimf — freepik.com

Работа над системой началась, песчинки множатся. Бизнес-аналитик небрежно оформил требование или опустил какой-то незначительный аспект реализации решения в ТЗ. В гору добавилась ещё одна песчинка, стрелка энтропии почти незаметно сместилась выше.

Разработчик базы данных неаккуратно заполнил описание поля в таблице или не заполнил его вовсе. Подумаешь, какая мелочь — в ТЗ же всё есть. Но новая песчинка уже неумолимо легла на своё место. Технический писатель перепутал слова в названии поля окна. Да кому какая разница, и так понятно. И потом, всё равно эту документацию никто читать не будет. Неужели, новая песчинка? Разумеется!

Всё это мелочи, незначительные крупинки. Но горячо любимые нами «костыли» и «велосипеды» — это уже не просто песчинки, а целые тачки, если не сказать, самосвалы песка. Да вы и сами прекрасно знаете, что творится в коде некоторых систем. Сейчас весь этот бардак политкорректно именуется «легаси».

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

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

Порядок в общем бардаке

Почему же частички мусора медленно, но неуклонно проникают в наши системы? Возможно, ответ поможет найти теория разбитых окон. Вот как излагают суть этой теории её авторы: «Если в здании разбито одно стекло и никто его не заменяет, то через некоторое время в этом здании не останется ни одного целого окна». Попробуем приложить эту теорию к процессу разработки систем. Разбитое окно — это тот самый мусор на входе.

Типичный унылый индустриальный пейзаж // Фото wirestock — freepik.com

Представим себе систему, код которой изобилует «подпорками» и «костылями», в которой есть множество недокументированных особенностей и неработающих блоков функциональности. По теории разбитых окон у этой системы сильно понижена «средняя планка допустимости мелких нарушений». Рано или поздно это приведёт к увеличению числа серьёзных ошибок.

Человек видит, что нарушения правил поведения другими членами социума не пресекаются, и, как следствие, перестаёт считать правила обязательными для себя (причём не только те, нарушения которых он наблюдал, но и любые другие).

На бытовом уровне теория разбитых окон иллюстрируется следующей фразой: «Если другим можно, то почему мне нельзя?» Если вы видите, что все вокруг постоянно нарушают правила, делают всё «спустя рукава», то будете ли вы считать себя обязанным поддерживать порядок в окружающем вас бардаке?

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

Конечно, против энтропии не попрёшь, она всё равно будет расти. Стремление мира к хаосу — фундаментальный закон природы. Но в наших силах хоть немного замедлить этот процесс. Или нет?...

Вообще, здорово, когда всё получается красиво, аккуратно и качественно. И не важно, что это — деревянная табуретка, программный код, или строительство дома. Чем меньше мусора будет поступать на вход, тем меньше его будет на выходе. А замедление роста энтропии станет дополнительным преимуществом.