[4/4] What Improves Developer Productivity at Google? Code Quality. (Filed under DevEx)

[4**/4] What Improves Developer Productivity at Google? Code Quality. (Rubric** #DevEx)

Read the article about developer productivity (1, 2 and 3) We will discuss the results obtained by the authors.

The top five factors that emerged from the analysis contained the following factors:

• Project code quality (code quality in the project)
• Hindrance of shifting priorities (Obstacles to changing priorities)
• Technical debt in projects (technical debt in projects)
• Innovation of infrastructure & tools (Innovation in infrastructure and tools)
• Overall satisfaction with infra & tools (general satisfaction with infrastructure and tools)

Next, the authors used a panel analysis with a delay. The bottom line is that they got a correlation between the productivity of the engineers and the factors above, and I would like to get stronger results and understand the direction of the connection. For this they put forward two hypotheses. 1) QaP: changes in code quality at T-1 It correlates with changes in engineers’ productivity over time T. As a formula, it looked like this: ΔPit = α + βΔQit−1 + Δ𝜖𝑖𝑡 2) PaQChanges in productivity at the time of T-1 correlates with changes in code quality at T. As a formula, it looked like this: ΔQit = α + βΔPit−1 + Δ𝜖𝑖𝑡 It turned out that the first hypothesis that the increase in code quality is associated with increased performance is confirmed with the following force.

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. But the inverse hypothesis is rejected, since it is not confirmed by experimental data. In fact, these results led to the title of the article, as well as a series of further studies that I mentioned in the article. piece 3 this review.

Separately, it is necessary to talk about the dangers to the validity of this experiment, which the authors described. All of them. 4 1) Content. The authors measured productivity by answering one question in a survey conducted by EngSat, which of course does not give the full picture. For example, the authors note that this question was about the individual productivity of the engineer, not the effectiveness of the team. Not all factors that may affect productivity have been considered. 2) Construct. Perceptions about productivity may differ among respondents. For example, someone could think about productivity in the format of fast fit feature, and someone took into account the difference in quality when creating the feature. Well, there were a number of places where respondents could perceive the questions themselves differently. 3) Internal. In this study, the authors use lag panel analysis, which effectively suggests that the effects on individual engineers are time independent. For example, one engineer changed the project and the team, another got the cool cops, the third something happened in the family. At the same time, there could be problems if some categories of engineers did not systematically participate in the survey, for example, veterans of development or vice versa beginners. But the authors controlled such deviations. 4) External. The whole experiment is based only on the experience of engineers inside Google, which means it may not have generalized power to other companies in the industry.

Despite all the potential challenges, I liked this study not only for its answer to the question of what improves developer productivity in Google, but also for its methodology.

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