Многие из нас сталкивались с ситуацией: приходит тим лид к разработчику и говорит, что нужно выбрать какую-нибудь библиотеку. Разработчик честно смотрит варианты, после чего отвечает: это все не то, надо самим писать. И ведь пишут! Пишут, даже если использовать готовое — это день, а писать самому — это месяц. Если повезет. Пишут, несмотря на срыв сроков и риски.
У такого подхода есть название: синдром «придумано не нами», или же «not invented here syndrome». Сокращенно — NIH. Известное когнитивное искажение, особенно широко распространено в разработке софта. По двум традиционным причинам, о которых я не устаю писать в каждой второй статье:
- Молодость индустрии: мы еще не знаем как «правильно» писать код, «лучшие практики» меняются каждые полгода. Код каждого программиста уникален и является отражением его картины мира. Читать чужой код — значит пытаться понять работу мозга у другого человека. Это как чужая одежда, сшитая на заказ. Тут слишком свободно, там жмет, здесь слишком много параметров у метода, а вон там, наоборот, слишком мало. Разработчикам тяжело понимать чужой код, поэтому возникает инстинктивное желание написать свой, сделать все «под себя», даже если это займет больше времени.
- Молодость индустрии: отсутствие фундаментального образования и культуры использования чужого кода. Выбирая решение задачи, разработчик делает выбор на основании своего жизненного опыта. Если разработчик всю жизнь писал код сам (а это, на секунду, четверо из пяти лично знакомых мне разработчиков) — ему просто не придет в голову использовать чужой код. А если коллеги предложат ему так сделать, то мозг автоматически будет сопротивляться такому предложению, так как не связанная с собственным жизненным опытом модель для него, мозга, будет «слабее» чем привычная. Автоматика, ничего личного.
Как и любое когнитивное искажение, NIH опасен своим иллюзорным миром, в котором «свое» — это «хорошо», а «чужое» — это «плохо». Решения, которые разработчик принимает в мире иллюзий, всегда кажутся ему правильными. Он даже будет отрицать объективную реальность, если она противоречит его внутренней модели мира. К счастью, разработка программ — не единственная область, где злобствует NIH, и за сотни лет человечество выработало приемы борьбы:
- Знание — сила. Если рассказать человеку о когнитивном искажении, то власть последнего сильно ослабевает. Конечно, физиологическая часть никуда не денется: даже зная о работе оптических иллюзий, человек все равно будет их видеть. И знание о NIH не защитит от «душевного порыва» переписать все самому. Зато знание поможет этот порыв распознать и попытаться с ним бороться.
- Стендап — хороший костыль для наших инстинктов. Никто не хочет демонстрировать слабость в коллективе. Одно дело сказать тим лиду «да я сам запилю за два дня» и потом месяц кормить его завтраками «уже почти все готово». Совсем другое дело каждое утро говорить это коллегам. Как правило, при наличии стендапа NIH приходит к разработчику один раз. После чего разработчик начинает ОЧЕНЬ аккуратно выбирать решения. Никто не хочет быть супергероем, сорвавшим все сроки.
- Open Source — не менее хороший костыль для наших привычек. Если в компании принято выкладывать библиотеки в open source, то у разработчиков появляются две полезные привычки. Во-первых, они привыкают к самой идее заимствования чужого кода, концепция перестает быть для них чем-то чужеродным. И, во-вторых, они становятся менее подвержены ползучему фичеризму и yagni: тяжело писать код «на всякий случай», если его принято показывать другим людям. Засмеют.
Эти и другие приемы позволяют уменьшить влияние NIH на команду. Но нужно всегда помнить, что иногда сон это просто сон NIH это вовсе не NIH. Бывают в нашей работе ситуации, когда существующие штуки действительно не подходят и нужно пилить свой велосипед. Задача тим лида и разработчиков — вовремя распознавать такие штуки. И, по возможности, не путать их с желанием нашего мозга избегать нового и непривычного.