Пуризм или прагматизм: Два подхода к культуре разработки

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

Понимание сути дискуссии

Мы решили использовать термины "пурист" и "прагматик" для обозначения каждой из сторон этого спора. В этих понятиях нет никакой философской подоплеки, я решил использовать их исходя из того, что они достаточно понятны.
Под пуристами мы понимаем традиционалистов или людей с четко определенным мировоззрением, чьи ценности и поведение как можно точнее отражают этот мир. Представьте себе разработчика программного обеспечения, который является убежденным сторонником agile или waterfall методологии и не желает поступаться своими принципами.
С другой стороны, прагматики - это люди с гибким мировоззрением. Они менее заинтересованы в следовании методике и больше ориентированы на результат. Если бы нам пришлось описать их основные убеждения одним предложением, то это было бы "все, что работает".
Реальность редко бывает такой чистой и легко определяемой, поэтому вместо того, чтобы рассматривать это разделение как две стороны медали, правильнее думать о нем в терминах континуума. Большинство из нас не являются жесткими пуристами или прагматиками, в нас есть и то, и другое.
Некоторым из нас нравится структурированность методологий, а другим - свобода и творчество более свободного подхода. Как бы то ни было, большинство из нас готовы идти на компромисс в подходящих условиях. К сожалению, это не всегда так, и именно здесь мы можем оказаться в тупике.

Когда методы имеют значение

Когда наш друг проводит семинар, он всегда рассказывает довольно забавную историю. Когда он начинал работать разработчиком программного обеспечения, первая работа, на которую он устроился, была в компании, которая с гордостью заявляла, что она на 100% занимается объектно-ориентированной разработкой.
В первом проекте нашего друга команда оказалась в тупике, поскольку у них возникла проблема, которую было нелегко смоделировать с помощью объектно-ориентированного подхода. Наш друг предложил несколько вариантов решения, оба из которых требовали императивного программирования, но его идеи были отвергнуты, поскольку это не соответствовало стилю компании.
Как бы смешно это ни звучало, но это реальная история, и вы будете удивлены, насколько она распространена. Это даже не обязательно парадигма программирования. Сторонники водопада или agile могут быть столь же жесткими в своих позициях, как и эта компания в своем подходе к разработке ПО.

Существует огромное количество причин, по которым это происходит. Одна из них - заблуждение о невозвратных затратах: некоторые компании потратили столько времени и усилий на освоение определенного подхода, что стали применять его во всем, даже если изначально он не был задуман с такой целью.
Я склоняюсь к менее циничному объяснению. Люди - существа традиционные и привычные, общества строятся на фундаменте ритуалов. Под обществом я подразумеваю все - от цивилизации до семьи, включая компании.
Идентичность компании отчасти определяется ее практикой и традициями. Фреймворки и методологии обеспечивают общий язык для всех членов компании, считая их семантическими сокращениями. Они позволяют нам быстро обмениваться информацией с людьми, которые разделяют наши взгляды.
Когда мы действуем вне рамок этого мировоззрения, общение становится более сложным, труднее донести суть, и мы рискуем нарушить шаблоны или вообще отделиться от сообщества.
Например, представьте себе компанию, которая настойчиво внедряет "шесть сигм", за исключением одного отдела, руководитель которого упорно придерживается других форм совершенствования процессов.
Если бы вы, как консультант, проверяли производительность каждого отдела, то вам было бы сложнее с этим отделом, поскольку его подход отличается от остальных, и оценить его эффективность по сравнению с другими сложнее.
Возвращаясь к моему другу, можно сказать, что он был прав, но что, если они внедрили решение, а через несколько лет после этого другая команда унаследовала проект и обнаружила этот странный императивный код в объектно-ориентированном программном обеспечении? Им, возможно, будет сложнее понять, как этот код должен работать.
Инновации по своей природе являются разрушительными, поэтому нередко они встречают сопротивление, особенно если эти инновации противоречат основным ценностям или социальным нормам группы.

Прагматичный разработчик

А теперь представьте себе абсолютную противоположность - разработчика программного обеспечения, который строит свой проект на основе чистого прагматизма: если это работает, то это работает. Я первым соглашусь с тем, что для большинства из нас это было бы замечательно - возможность писать код так, как хочется.
К сожалению, это просто нереально. Когда мы пишем код, особенно для других, мы должны понимать, что, возможно, мы не будем существовать вечно. Поэтому наша работа не может быть идиосинкразической, она должна быть способна передать замысел, должна иметь структуру, чтобы другие могли следовать за ней.
Конечно, это опять-таки крайний пример. Прагматики не являются мастерами хаоса, они просто считают, что найти решение проблемы важнее, чем соблюдать набор определенных норм или традиций, которые могут быть сдерживающими.
Пожалуй, самым ярким примером прагматичных разработчиков являются те, кто применяет гибридные методологии, сочетая структуру водопадного подхода с быстрой доставкой и вовлечением пользователей, характерными для agile.
Общей чертой прагматиков, как правило, является уровень их опыта. Старшие разработчики более склонны к экспериментам и меньше полагаются на традиционные подходы.
Например, подавляющее большинство людей, работающих с Clojure (функциональный язык программирования на Java), - это разработчики старшего поколения, которым надоело работать с объектно-ориентированным программированием.
И это не редкость. Как утверждает Хун в своей книге о научных революциях, у каждой парадигмы есть предел, точка, где она ломается. Именно тогда специалист понимает, что для решения его проблемы нужна новая парадигма.
Если структура обеспечивает общие рамки, то инновации - это то, что раздвигает эти рамки до предела. Альтернатива довольно удручающая: традиционализм способствует стагнации. Если мы будем придерживаться наших безопасных и надежных методов, то дойдем до точки, когда мы просто не сможем адаптироваться.
А это последнее, что нам нужно в бизнесе, который ускоряется с каждой минутой.

Противоположности дополняют друг друга

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