Изоляция наушников - лучший способ создать качественное программное обеспечение?

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

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

Тем не менее, вопросы остаются:

  • Действительно ли они продуктивны?
  • Является ли изолированная работа лучшим способом создания качественного программного обеспечения в долгосрочной перспективе?

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

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

Хотя это определение поначалу может показаться полным, в нем не учитывается качество производимого программного обеспечения. Все становится намного сложнее, когда мы добавляем качество в смесь и начинаем измерять другие аспекты, такие как время обслуживания, ошибки, время на привлечение новых разработчиков и то, как долго программное обеспечение может жить без серьезных рефакторингов. Дело в том, что уровень желаемого качества может варьироваться в зависимости от организации и сильно зависит от уровня их зрелости, размера команды и сценариев использования.

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

Стартапы и миф о 10X разработчиков

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

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

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

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

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

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

В настоящее время при работе с распределенными архитектурами (микросервисы, Lambda, облачные сервисы и т. Д.) Есть тысячи возможных решений каждой проблемы. DevOps и облако сняли часть бремени управления физическими серверами, но они также увеличили сложность взаимодействия программного обеспечения (очереди, API) и объем необходимого планирования.

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

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

Вот некоторые из тех, с которыми я лично столкнулся:

Офис открытого типа

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

Ловкость, спринты, отсутствие простоев

В настоящее время большинство организаций приняли какую-то методологию Agile / Scrum. Спринты обычно забиты билетами до краев, оставляя практически нулевое пространство для команды, которая может находиться в режиме ожидания или даже иметь время для обсуждений. Конец спринтов напоминает время кризиса, когда люди работают как можно быстрее, чтобы диаграммы выгорания выглядели так, как нужно. В среде, где есть постоянный двухнедельный крайний срок, трудно остановить работу даже на 15 минут и втянуть команду в какое-либо обсуждение.

Управление

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

Заключение

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

Этот способ измерения производительности прост и иногда работает. Однако он так же эффективен, как подсчет строк кода, и может в конечном итоге вернуться в виде технического долга.

Активное сотрудничество (включая парное программирование) - очень продуктивный способ обеспечить качество в долгосрочной перспективе. Мы не только делимся знаниями с товарищами по команде, но и быстрее получаем обратную связь. Мне нравится видеть, как люди работают вместе, решают проблемы в команде и не боятся спросить совета. Однако иногда бывает трудно избавиться от позиции «оставь меня в покое». Чтобы решить эту проблему, я рекомендую иметь удаленные сайты. Вывести команду из офиса для обсуждения, создания прототипов или просто для повседневной работы, позволяя им сотрудничать без необходимости объяснять себя или отвлекать других людей, - это хороший способ зажечь и расширить сотрудничество в команде.

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