Каковы возможные недостатки парного программирования? [закрыто]

Сегодня парное программирование довольно известно.

У этого есть несколько преимуществ как:

1. Программы с меньшим количеством ошибок.
2. Стоимость постпроизводственного обслуживания намного меньше.
3. Сложившаяся практика ставится под сомнение, что приводит к появлению новых идей.
4. Программисты учатся друг у друга.
5. Программисты развивают мягкие навыки.

Но каковы недостатки парного программирования?

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

Вот некоторые из них:

1. В парном программировании вы не можете сидеть сложа руки и самостоятельно оценивать свой собственный код.
2. Одна из пары может перестать активно участвовать.
3. Драйвер должен "программировать вслух". Тихое программирование уменьшает выгоду.
4. Производить те же функции стоит больше человеко-часов. Необходимо поддерживать баланс между качеством кода и увеличением стоимости кодирования.
5. Феномен «следи за хозяином» может возникнуть, когда опытный и начинающий программист объединятся. Начинающий участник может стать наблюдателем, а опытный участник завершит большую часть кодирования.
6. Когда два опытных пользователя объединяются, может возникнуть феномен «эго разработчика», при котором каждый участник пытается выдвинуть свои собственные идеи.

Я несколько раз пытался создать парное программирование, в том числе в организации, которая (кратко) рассматривала развертывание как обязательный процесс для всех инженеров (вы можете догадаться, насколько удачной оказалась эта идея). Лично я ненавидел это.

Причины, которые я перечисляю ниже, являются только моим субъективным опытом, и я не могу «измерить» их влияние в конкретных терминах. Но вот они все одинаковые

1 - Наличие «навигатора» и «водителя» помогает только в том случае, если первый вокал, а второй будет слушать.

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

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

2 - Спаривание мешает творчеству.

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

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

3 - Самый низкий общий дизайн знаменателя.

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

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

4 - Отсутствие автономии и насильственной прозрачности.

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

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

5 - Некоторые разработчики просто плохо играют в парах.

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

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

Зависит от вашей ситуации или перспективы.

Парное программирование хорошо для организации. Но хорошо ли это для человека?

В конце концов, это экономия (ранняя обратная связь) и метод производительности; Речь идет не о вас, а о проекте, продукте, компании ($$).

Хотя у вас могут быть личные выгоды, они не являются причиной или концом какой-либо методологии разработки. Например, парное программирование (полный рабочий день) также не дает вам расслабиться, заниматься серфингом и т. Д., Вы должны оправдать свои паузы своему партнеру.

Ваш (вращающийся) партнер будет лучшей камерой наблюдения: интенсивность работы увеличивается.

Или, распределяя знания, человек становится менее рискованным для компании (например, не может покинуть компанию с необходимыми знаниями) и получает меньше «фишек для переговоров».

Я уверен, что вы найдете больше очков, читая позитивные статьи более критически с ВАШЕЙ реальной ситуации / точки зрения в компании, а не с точки зрения вашего менеджера.

Почти все методологии написаны с точки зрения менеджера.

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

2. Вы должны соблюдать гигиенические стандарты другого человека.

В дополнение к другим ответам:

1. Многие компании, над которыми я работал, выпускают свои программисты с ноутбуками (базируются на сайтах клиентов - легче поддерживать оборудование в безопасности, если его забирают домой после работы, в состоянии уклоняться от выполнения домашней работы по VPN в крайнем случае и т. Д.) Много лет назад у меня уже были проблемы с просмотром на экране ноутбука другого человека («водителя») с точки зрения серфинга на плечах - возраст не улучшит это (и в любом случае некоторые экраны становятся трудными для чтения за пределами идеального угла обзора).

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

2. Я также обнаружил, что различия в личных гигиенических предпочтениях (включая курение, еду и питье), а также личные столкновения неизбежно снижают производительность труда. Достаточно легко сказать двум программистам «смириться с этим и ладить», часто это приводит к тому, что люди предпочитают держать язык за зубами и молча саботировать друг друга с помощью пассивно-агрессивных действий, чтобы выразить свое негодование по отношению друг к другу.
3. Шум. Мне, например, нравится спокойная рабочая обстановка. Я не могу представить постоянную болтовню от некоторых групп программистов пары (поскольку вам нужно поговорить для общения). Даже вокальная музыка на моих наушниках мешает моей концентрации (мягкие инструменталы для прослушивания в офисе ...). Я думаю, что это можно смягчить, переместившись из вездесущего офиса с открытой планировкой в ​​выделенные офисные помещения на 2 человека, но это снова приведет к увеличению затрат.

Анекдоты для вашего развлечения:

• Предыдущий работодатель однажды привлек подрядчика из другой страны (чтобы анонимность оставалась для защиты виновных). Работодатель предоставил жилье, но не транспорт. Поскольку указанный подрядчик жил на моем пути к работе, я вызвался взять его и высадить снова. Допустим, его личная гигиена не соответствовала тому, к чему я привык, и он также много курил («самый сильный!»), А я нет. Во время нашей 15-минутной поездки в офис я держал свое окно опущенным - даже зимой - что не помешало моей машине пахнуть как устаревшая курительная комната после 3-месячного пребывания коллеги (нет, он не курил в машине , но он сделал, пока меня ждал).
• Мы также не занимались парным программированием, но сидели рядом за столом переговоров (какое-то время). Примерно через месяц на искусственной древесине стола появилось красивое коричневое кольцо, на котором лежала рука коллеги. В этот момент я получил открытую парту рядом с открытой планировочной площадкой call-центра, которую я предпочел (с некоторой помощью моих наушников).
• Тогда есть вездесущий офисный напиток: кофе. Хотя я пью его, я могу обходиться без него и не пить так часто, как другие коллеги. Дыхание с близкого расстояния может быть довольно неприятным - похоже на запах пустой забытой кружки. Давайте назовем аромат "душным" ...

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

Что неизбежно произойдет через некоторое время, так это то, что пара разделилась на «проверку электронной почты» или «вы продолжаете проверять эту проблему» и т. Д.

Вместо того, чтобы улучшать вывод кода, объем уменьшается. И по практическим соображениям «мне нужно пойти на обед / встречу с вами синхронно» и по общению «Я просто подожду, пока Боб закончит то, что он делает, прежде чем я спрошу о повторном соединении, я не хочу, чтобы меня видели, как его надоедают»

Что касается хваленых преимуществ, есть много общих практик, которые достигают их более простыми и эффективными способами

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