Развенчание мифа о собственной продуктивности программистов

Введение

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

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

На основе исследования, приведённого ниже будет ясно, что:

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

Эти важные открытия означают следующие вещи:

1. нормальная изменчивость мешает попыткам измерить производительность. Это оказывает серьёзное влияние на планирование, измерение и оценку улучшений производительности и процесса разработки;
2. руководители проектов могут только примерно оценить производительность отдельных разработчиков, даже при наличии значительных примеров работы;
3. эти же самые руководители обладают другими инструментами для улучшения производительности.

Исследования по теме

В наше время считается очевидным, что продуктивность программистов варьируется в широких пределах. Стив Макконнел и Роберт Глас сделали обзор следующих исследований: Сакман, Куртис (1981 и 1988), Майерс и Демарко. Обзор показал разницу в личной производительности от 10-и до 28-и раз. Боэм пришёл к выводу о четырёхкратной разнице для команд, а Демарко считает, что команды могут отличаться на столько же, на сколько и разработчики.

Наиболее значительная критика представлена в работе Лутца Пречелта, pdf, который утверждал, что правильнее смотреть на распределение, а не на отношение статистических выбросов.

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

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

Новое исследование

Чтобы лучше понять продуктивность программистов в данном исследовании использовались данные собранные в ходе преподавания курса "личный процесс разработки ПО" (ЛПР). В данном курсе (1995) мы обучали разработчиков, как измерить личную производительность и реализовать собственный цикл Деминга. В основе курса — стабильность личного рабочего процесса и его измерения. В рамках преподавания курса, мы ежедневно собирали и демонстрировали классу информацию о прогрессе. Таким образом преподаватели могли видеть, как меняется личная производительность на разных заданиях.

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

Данное исследование использовало версию курса с десятью упражнениями. Из 3800 разработчиков (2000-2006 гг.) лишь 494 использовали язык C и реализовали все 10 задач. Средний опыт слушателей составил 3,7 лет. Половина имели опыт менее года. Самый опытный имел стаж 36 лет. Производительность тут измеряется как отношение трудозатрат к среднему по группе для конкретной программы. Не имея объективного метода сравнения программ напрямую, эта относительная шкала не показывает абсолютной производительности на всём наборе программ. Но так как данное исследование относится к программистам, а не к программам, такой подход более чем оправдан.

Рис. 1 показывает квартили продуктивности для каждого из 10 заданий. Следует отметить два момента:

• Похоже, что некоторые программисты всё-таки лучше других. Если посчитать соотношение лучших к худшим для каждого из задания, то можно увидеть соотношения 55:1 (задание 1) и 21:1 (задание 7). Такой разброс согласуется с результатами представленными в обзоре литературы
• Однако если отбросить выбросы, нет свидетельств сильного превосходства одних разработчиков над другими. На диапазоне между 25-ым и 75-ым процентилями равномерность продуктивности просто поражает (в зависимости от задачи разница между третьим и первым квартилем лежит в пределах от 0,6 до 1,25)

Рис. 1. Тренд относительных трудозатрат разработчиков, квартили и диапазон

Тут въедливый читатель заметит: "Что и требовалось доказать! Некоторые разработчики всегда в числе лучших!" То есть, если какие-то разработчики оказываются в червёртом (верхнем) квартиле на всех задачах, то этих лучших программистов и надо нанимать. Но на практике оказывается, что разработчики постоянно попадают в разные квартили. Это подтверждается вариацией ранга индивидуальной продуктивности.

Рис. 2 показывается разнообразие результатов разных программистов на разных задачах. Эти данные были получены следующим образом: каждому участнику был присвоен ранг от 1-го до 494-х на каждой задаче, в зависимости от того, с какой скоростью он справился с задачей. Для каждого разработчика эти ранги были отражены на графике:

• Медиана — синяя линия
• Доверительный интервал — "усы". Полный диапазон для каждого программиста не отображён на графике.

Рис. 2. Среди 494-х программистов (ось X), имеет место широкий доверительный интервал производительности (ось Y) на разных задачах

На графике заметно несколько важных эффектов:

• Безусловно, есть несколько программистов, которые стабильно решают задачи быстрее других (см. диапазоны меньше 50-и) и те, кто стабильно решают задачи медленнее других (см. диапазоны выше 450-и)
• Однако, вне этих групп, доверительные интервалы очень широки. Для 90% разработчиков, имеется очень большой разброс времени выполнения отдельных заданий.
• Более того, это результат должен предостеречь руководителей от оценки личной производительности программистов, так как эта метрика имеет смысл лишь для небольшой доли сотрудников. Вместо этого, намного полезнее будет изучить причины разброса производительности разработчиков на каждой задаче.

Как бы подчёркивая последний пункт, распределение относительных трудозатрат (таблица 1) показывает, что 90% программистов попадают в группу умеренной производительности. Средний коэффициент вариабельности для отдельных программистов (42%) не сильно меньше общей вариабельности. Фактически 482 из 494-х программистов закончили хотя бы одно задание быстрее среднего, а 415 — медленнее. Резюмируя, эти показатели демонстрируют, что скорость выполнения заданий определяется случайными неизвестными факторами в той же мере, что и истинной собственной производительностью разработчиков.

Таблица 1. Распределение относительной производительности

Последствия для руководителей

Широкие рамки производительности показывают, что даже опытные программисты не сохраняют одинаковую скорость работы на разных заданиях. Нанимать "лучших программистов" не будет настолько эффективным, насколько нам хотелось бы. Тем не менее, мы рекомендуем руководителям следующее:

1. Принять непредсказуемость даже простых заданий. Декомпозировать всё на маленькие задачи и ориентироваться на тренд, а не на краткосрочные результаты
2. Собирать много данных для новых инструментов или улучшений процессов. Большинство заданий будут закончены на менее чем на 15% быстрее чем среднее. Естественный разброс может скрыть даже значительные эффекты.
3. Устанавливать достижимые цели основанные на реалистичных исторических данных о средних и вариациях. Так как некоторые задания потребуют больше времени, чем ожидается, следует начинать большие и критические задания раньше.
4. Обращать внимание на важность проектирования для контроля сложности и объёма решений.
5. Поощрять регулярные взаимные обзоры кода. Значительная доля разброса является результатом не оптимального выбора реализации либо исправления сложных ошибок. Дополнительная пара глаз не только заметит альтернативное решение, но и познакомит коллег с другими подходами.
6. Обеспечить разработчиков тихой рабочей средой, где они могли бы сфокусироваться на решаемых задачах без того, чтобы их отвлекали.
7. Помогать разработчикам, которые хотят развиваться. Обеспечить возможности для профессионального роста и рабочую среду в которой они могли бы улучшить свои навыки работая за пределами зоны комфорта.
8. Не концентрироваться на скорости разработки. Например, уменьшение количества дефектов — поддающееся тренировке умение (Ромбах, 2008). Оно не уменьшает производительность, но уменьшает вариативность скорости и уменьшает общую стоимость жизненного цикла.

В целом, несмотря на то, что некоторые программисты лучше и/или быстрее других, важность этого сильно преувеличена. Вместо того, чтобы наклеивать ярлыки, типа "лучший" или "худший", лучшим способом увеличить среднюю производительность будет увеличить производительность каждого. Опыт тут важен, но ограниченно. Следующие рекомендации должны помочь программистам и руководителям собирать данные и повышать производительность: Определите процесс разработки; измеряйте трудозатраты; считайте, классифицируйте и измеряйте дефекты; измеряйте продукт; оценивайте объём продукта и затраты на разработку; делайте обзоры кода по списку; проводите демонстрацию и обзоры проекта.