[4/4] What Improves Developer Productivity at Google? Code Quality. (Рубрика DevEx)

Закончим рассмотрение статьи про developer productivity (1, 2 и 3) и обсудим полученные авторами результаты.

Топ пять факторов, что получились после анализа содержали следующие факторы

• Project code quality (качество кода в проекте)
• Hindrance of shifting priorities (препятствия в изменении приоритетов)
• Technical debt in projects (технический долг в проектах)
• Innovation of infrastructure & tools (инновации в инфраструктуре и инструментах)
• Overall satisfaction with infra & tools (общая удовлетворенность инфраструктурой и инструментами)

Дальше авторы применили панельный анализ с запаздыванием. Суть в том, что они получили корреляцию между продуктивностью инженеров и факторами, что приведены выше, а хотелось бы получить более сильные результаты и понять направление связи. Для этого они выдвинули две гипотезы 1) QaP: изменения в качестве кода в момент T-1 коррелирует с изменениями в продуктивности инженеров во времени T. В виде формулы это выглядело так: Δ𝑃𝑖𝑡 = 𝛼 + 𝛽Δ𝑄𝑖𝑡−1 + Δ𝜖𝑖𝑡 2) PaQ: изменения в продуктивность в момент T-1 коррелирует с изменениями в качестве кода в момент T. В виде формулы это выглядело так: Δ𝑄𝑖𝑡 = 𝛼 + 𝛽Δ𝑃𝑖𝑡−1 + Δ𝜖𝑖𝑡 Оказалось, что первая гипотеза о том, что рост качества кода связан с повышением производительности подтверждается со следующей силой

We found that a 100% increase of satisfaction rating with project code quality (i.e. going from a rating of ‘Very dissatisfied’ to ‘Very sat- isfied’) at time T-1 was associated with a 10% decrease of median active coding time per CL, a 12% decrease of median wall-clock time from creating to mailing a CL, and a 22% decrease of median wall-clock time from submitting to deploying a CL at time T. А вот обратная гипотеза отвергается, так как она не подтверждена экспериментальными данными. Собственно, эти результаты и привели к названию статьи, а также к целой серии дальнейших исследований, что я упоминал в части 3 этого обзора.

Отдельно надо рассказать про опасности для валидности этого эксперимента, которые описали авторы. Их всего 4 1) Content. Авторы измеряли продуктивность по ответу на один вопрос в проводимом EngSat опросе, что конечно не дает полной картины. Например, авторы отмечают, что этот вопрос был про индивидуальную продуктивность инженера, а не про эффективность команды. Примерно также не все факторы, что могут влиять на продуктивность были рассмотрены 2) Construct. Восприятие вопроса про продуктивность могло отличаться у респондентов. Например, кто-то мог думать о продуктивности в формате нафигачить быстро фичу, а кто-то учитывал разницу в качестве при создании фичи. Ну и там был еще ряд мест, где респонденты по разному могли воспринять сами вопросы 3) Internal. В этом исследовании авторы используют панельный анализ с запаздыванием, что эффективно предполагает, что эффекты на индивидуальных инженеров не зависят от времени. Например, у одного инженера сменился проект и команда, другому достался крутой ментов, у третьего что-то случилось в семье. Одновременно, могли бы быть проблемы, если какие-то категории инженеров систематически не участвовали в опросе, например, ветераны разработки или наоборот новички. Но авторы такие отклонения контролировали. 4) External. Весь эксперимент основывает только на опыте инженеров внутри Google, а значит может не иметь обобщающей силы на другие компании в индустрии.

Несмотря на все потенциальные проблемы, мне понравилось это исследование не только итоговым ответом на вопрос про то, что улучшает developer productivity в Google, но и самой методологией проведения эксперимента.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes