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

Наконец-то я дочитал и написал разбор этого whitepaper 2022 года, что пролежал распечатанным на моем столе около года. Не могу сказать, что заставило меня остановиться при первом прочтении на полпути, возможно это 16 страниц убористого шрифта, а возможно наличие целых 40 параметров анализа того, что влияет на продуктивность инженеров, но я с этим справился:) Оказалось, что треть этих страниц - это аппендиксы, а из 40 параметров авторы выделили целых 6, что оказались статзначимы и сильно влияли на продуктивность. В условиях Google эти пять параметров такие: code quality, technical debt, infra tools & support, team communications, goals & priorities, org change & process. Собственно, первое место заняло code quality, поэтому его проанализировали поглубже и вынесли в название статьи. Если говорить про статью в общем, то она очень интересная и если вы планируете исследовать тему developer productivity у себя в компании, то очень рекомендую изучить эту статью, так как авторы рассказывают в деталях о методологии, пишут формулы и проводят анализ того, что может нарушить валидность модели (этого часто не хватает во многих других исследованиях, что попроще).

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

What causes improvements to developer productivity in practice? который для меня кажется похожим н классические вопросы "Кто виноват" и "Что делать"

Авторы делают обзор предыдущих исследований на эту тему, но делают вывод, что 1) Из контролируемых экспериментов можно понять причинно-следственные связи, но не ясно будут ли они воспроизводиться на рабочем месте. Эти эксперименты обычно ставятся в таких условиях, когда экспериментаторы привлекают студентов или даже опытных специалистов и устраивают им аля лабораторные работы, навроде, дебаггинга новым инструментом по сравнению со старым. 2) Полевые исследования могут дать валидные наблюдения в контексте организации, но их сложно обобщить, а также есть проблемы с определением не просто корреляций, а причинно-следственных связей.

Основной вклад этой статьи в исследования продуктивности - возможность получить более строгий вывод о факторах, что причинно-следственно влияют на продуктивность инженеров. Для этого авторы решают использовать подход под названием "panel data analysis" (панельное исследование). Если объяснять на пальцах, то в таких исследованиях данные собираются за определённое время у одних и тех же групп людей или индивидов, а затем проводится регрессия. То есть в широком смысле панельное исследование - это синоним лонгитюдного исследования.

Стандартным форматом для проведения исследований продуктивности является использование cross-sectional data (перекрёстных данных). Если объяснять на пальцах, то в таких исследованиях данные собираются путём наблюдения за объектами в один и тот же период времени. Обычно это проще всего сделать, бахнув опрос, но тут есть проблемки.

А про них мы поговорим в следующей части обзора.

P.S. Интересно, что по результатам этого исследования родилась куча отдельных статей на отдельные темы, многие из которых попали в колонку IEEE про developer proudctivity, о которой я уже рассказывал. Причем эту колонку видут соавторы рассматриваемой в этом посте статьи:)

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