Всем известный закон Мёрфи гласит: «Если что-то плохое может случиться, то оно обязательно произойдет». Согласитесь, не самая позитивная установка, особенно когда это касается работы. И тут мне стало любопытно, а есть ли такие законы, которые мне, как ИТ-специалисту, максимально помогут избежать «чего-то плохого». К своему удивлению, я их нашел, и даже не один. Потому делюсь с вами сегодня своими сакральными знаниями в блоге ЛАНИТ. 

Закон тривиальности Паркинсона

Однажды я участвовал во встрече по обсуждению крупной фичи, и половину времени, отведённого на обсуждение, мы выбирали цвет кнопки на одном из экранов.

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

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

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

Спустя год в книге Parkinson’s Law Or the Pursuit of Progress Паркинсон переформулировал закон. Он описал работу комитета по строительству АЭС. Как оказалось, в процессе обсуждения люди меньше всего времени тратили на технические характеристики атомной электростанции и другие важные  факторы. Почему-то всех больше волновал сарай, куда можно будет ставить велосипеды. С 1958 года закон начал звучать следующим образом: «Люди в обсуждениях уделяют гораздо больше времени банальным или косметическим вопросам, нежели серьезным и существенным».

В мир ИТ закон пришел, конечно же, не сразу. Это случилось благодаря датскому программисту Поул-Хеннингу Кампу, который употребил его в своей email-рассылке 1999 года. Так закон и нашёл своё применение в разработке программного обеспечения. В специализированной англоязычной литературе даже появился термин bike-shed effect, что переводится как «эффект велосипедного сарая», ставший синонимичным понятием закона тривиальности.

Закон Брукса

У кого было такое, что проект, связанный с разработкой ПО, не укладывался в сроки и руководитель проекта предлагал просто подключить ещё людей? Полагаю, что я не один такой счастливчик. И это, скорее всего, абсолютно не помогло. Почему так? На этот вопрос дал ответ американский ученый Фредерик Брукс.

В 1975 году он выпустил книгу под названием «Мифический человеко-месяц, или Как создаются программные системы». В 1979 году она вышла на русском языке. По сути это сборник очерков, которые Брукс писал во время его работы в IBM. В нем отражены основные трудности и пути их решения, с которыми руководители сталкиваются на крупных программных проектах.

Журнал PC World отдал этой книге первое место в списке «Десять ИT-книг, которые стыдно признать, что не читал». Значение работы Брукса было отмечено самыми влиятельными журналами, которые писали об информационных технологиях. Все они в один голос говорили о том, что это своего рода бестселлер мира ИТ.

Так может быть, прежде чем приступать к новому программному проекту, все-таки имеет смысл почитать Фредерика Брукса?

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

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

Кроме того, разработчики в среднем тратят 20% времени на коммуникации друг с другом, и добавление нового члена команды в их структуру лишь всё усложнит.

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

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

Закон Иглсона

Сталкивались с таким? Внезапно в программе что-то ломается, вы долго ищете причину, а в итоге оказывается, что это вы сами и написали пару лет назад. И первая ваша мысль: «Нет, я не мог такое написать, меня подставили»!

На самом деле Иглсон был еще тем оптимистом: на практике достаточно и трёх недель. Доподлинно неизвестно, кем был Иглсон и когда он придумал свой закон. Путешествуя по различным интернет-ресурсам, мне удалось найти два варианта происхождения закона. На одном из форумов было обнаружено сообщение с этим законом еще в 1991 году. Скорее всего он возник в частной сети. Это подтверждается файлом comp.fortune за 1987 год, где цитировался закон Иглсона.  

Но на самом деле такое отношение к своему коду не является чем-то плохим. Если вы оглядываетесь на свой старый код и внутренне съеживаетесь – это означает, что с тех пор вы чему-то научились и стали лучше.

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

Закон кибернетической энтомологии

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

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

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

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

Этот и другие законы, о которых я сегодня упоминал, отчасти шуточные и гиперболизированные, но я надеюсь: каждый из них поможет вам чуточку иначе взглянуть на мир вокруг вас, особенно такой сложный и непостоянный как мир ИT.

Наконец, как говорил Станислав Ежи Лец, не стоит забывать, что незнание законов не освобождает от ответственности, а вот знание - нередко освобождает.

Делитесь в комментариях историями о том, с какими законами мира ИТ вы сталкивались во время своей работы.

P.S. Этот материал я подготовил в рамках «Школы спикеров ЛАНИТ», который принес мне победу на TED-конференции.