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

Продолжим рассмотрение статьи про developer productivity обсуждение проблем опросов, которые часто используются для ответов на вопросы о продуктивности.

Представим опрос про связь самооценки продуктивности инженеров и воспринимаемого уровня качества кода. Даже получив результаты опросы, у нас эффекты, что мешают вывести причинно-следственную связь между качеством кода и продуктивностью
1) Time-invariant effects - эти эффекты имеют тот же самый эффект в разные моменты времени, например, уровень образования респондентов
2) Respondent-independent time effects - это эффекты, которые влияют на респондентов одинаково, например, сезонные эффекты или крупные инициативы на всю компанию
3) Non-differentiated response effects - это эффекты, когда респонденты склонны давать одинаковый ответ на все вопросы. У одного респондента это может быть средний вариант ответа на все вопросы, а у другого самый высокий.
Но в панельном исследовании есть возможность устранить эти эффекты, анализируя данные за разные промежутки времени, а также есть возможность попробовать установить не только корреляции, но и причинно-следственные связи. Дальше авторы описывают связанные научные работы и показывают как обычно использовались time-series данные и что их можно использовать для ответов на часть вопросов, изначально поставленных в исследовании. Правда, эти эти способы не использовались раньше для анализа developer productivity, а также они не подходят для того типа данных, что используют авторы этого исследования.

Дальше авторы переходят к рассказу о методах панельного исследования, где в качестве источников данных используются
1) Данные из логов использования внутренних инструментов, навроде, данных о редактировании файлов, билдах, работе в системе codee review и так далее. Важно отметить, что эти данные содержат хорошо гранулированную историю о работе инженеров, что точно измерять поведение инженеров и характеризовать используемые ими рабочие практики и задачи, которые они выполняют при этом.
2) Данные лонгитюдных исследований (опросов), которые проводятся посредством EngSat (engineering satisfaction survery). Это долговременные исследования в виде опросов, ответы на которые собираются каждый квартал у трети инженеров. Подробнее про них в отдельном whitepaper "Measuring Developer Experience With a Longitudinal Survey", про который я уже рассказывал.

Дальше описываются зависимые и независимые переменные, которые используются в модели исследования и объясняется как мы строим модель, чтобы ее можно было ответить на изначальные вопросы исследования. В качестве зависимых переменных используются самооценки продуктивности инженеров, которые взяты из опросов. С одной стороны именно эту переменную исследовали в других исследованиях и выявили некоторую корреляцию между субъективным и объективными исследованиями. В качестве объективных метрик были взяты следующие три категории метрик
1) The amount of output (per quater) - тут было 2 метрики: total number of changelists и total lines of code
2) The amount of time per item (changelist) - тут было 2 метрики: median active coding time, median well-clock coding
3) The amount of time for non-productive activities - тут было 2 метрики: median wall-clock review time и median wall-clock merge time

Для анализа авторы собрали данные 6 последовательных кварталов с 2018Q1 по 2019Q2. Для анализа у исследователей накопилось порядка 2к точекк и дальше они построили модельку, что на рандомно выбранных 10% данных для валидации получили 83% precision и 99% recall. Причем основным предиктивным фактором оказался Median Active Coding TIme, что кажется логичным.

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

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