В 1999 году второй автор этой статьи (Лори Вильямс) провел в университете Юта эксперимент по выяснению экономических аспектов парного программирования. В нем участвовали студенты старших курсов, обучавшихся по специальности "Software Engineering". Треть группы писала программы обычным способом - то есть, в одиночку. Остальные работали над проектом в паре с партнером. На рисунке 1 вы видите, сколько времени затратили на выполнение заданий первая и вторая группы студентов. После начального периода "притирки" партнеров, которая проходила во время работы над первой программой, пары программистов тратили всего на 15% больше времени, чем индивидуалы. Как видите, парное программирование отнюдь не удваивает стоимость разработки!

Рисунок 1: Время, затраченное на выполнение контрольных заданий

Важно отметить, что получившийся в результате парного программирования код содержал на 15% меньше ошибок, чем код индивидуалов. (Эти результаты подтверждены статистикой.) На рисунке 2 показано, с каким успехом проходили тестирование программы, написанные студентами обеих групп (иными словами, процент успешно пройденных тестов, которые писал инструктор).

Рисунок 2: Ошибки в программах

Изначальное 15% увеличение стоимости разработки окупается за счет уменьшения количества ошибок. Проиллюстрируем это положение наглядным примером. Предположим, что программа в 50 000 строк кода (50 000 LOC) разрабатывается группой программистов-"одиночек" и группой программистов, работающих в парах. При типичной скорости разработки 50 LOC в час "одиночки" напишут эту программу за 1000 часов. "Пары" затратят на ту же задачу на 15% больше, то есть 1150 часов. Таким образом, стоимость разработки вырастает на 150 часов. Основываясь на статистических данных, программист совершает 100 ошибок на 1000 строк кода. Правильно поставленный процесс разработки позволяет выявить около 70% этих ошибок. Следовательно, у "одиночек" в программе останется порядка 1500 ошибок, в то время как у "пар" их будет на 15% (на 225) меньше - 1275 ошибок.

В некоторых компаниях программный код передается в отдел тестирования или контроля качества, который находит и исправляет существенную часть оставшихся в программе ошибок. Обычно при проведении системных тестов на одну ошибку уходит от четырех до шестнадцати часов. Возьмем нечто среднее - 10 часов, тогда получится, что на исправление этих "лишних" 225 ошибок отдел тестирования потратит около 2250 часов. А это в 15 раз больше, чем изначальное увеличение затрат на парное программирование - 150 часов!

Если же по окончанию работ программа отправляется непосредственно заказчику, то парное программирование оказывается еще более выгодным. По данным статистики, после выхода программы в эксплуатацию на исправление одной ошибки уходит от 33 до 88 часов. Возьмем оптимистичный вариант - по 40 часов на ошибку, тогда если клиет обнаружит 225 дополнительных ошибок, это будет стоить компании-разработчику 9 000 часов - в 60 раз больше, чем те затраты, которые требовались при использовании парного программирования!

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

Если парное программирование не будет доставлять удовольствие, то программисты не будут его использовать.

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

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

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

Рисунок 3: Удовлетворение от работы

Как заметил один из программистов,

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

На эту тему есть еще один замечательный комментарий :