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

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

I finally finished reading and wrote a review of it. whitepaper 2022 I have been on my desk for about a year. I can't tell you what made me stop at the first reading halfway through, maybe that's it. 16 pages of clean font, and possibly the presence of whole 40 I was able to analyze the parameters of what affects the productivity of engineers, but I managed to:) It turned out that a third of these pages are appendixes. 40 The authors have identified the entire parameters. 6They were significant and greatly affected productivity. In Google’s terms, these five parameters are: code quality, technical debt, infra tools & support, team communications, goals & priorities, org change & process. In fact, the first place was taken by code quality, so it was analyzed deeper and brought to the title of the article. If we talk about the article in general, it is very interesting and if you plan to explore the topic of developer productivity in your company, then I highly recommend studying this article, since the authors tell in detail about the methodology, write formulas and analyze what can violate the validity of the model. (This is often lacking in many other studies, which are simpler.).

Well, now we move inside the article and it begins with the fact that organizations want to maximize the productivity of software development, or rather make the best software in the shortest possible time. This question can be viewed from different angles, but the question of individual productivity of engineers is fruitful. The article begins with a research question.

What causes improvements to developer productivity in practice? Which to me seems like the classic "Who's to blame" and "What to do."

The authors review previous studies on the topic, but conclude that 1) It is possible to understand causal relationships from controlled experiments, but it is not clear whether they will be replicated in the workplace. These experiments are usually conducted in such conditions, when the experimenters attract students or even experienced specialists and arrange them ala laboratory work, like debugging a new tool compared to the old one. 2) Field studies can provide valid observations in the context of an organizationBut they are difficult to generalize, and there are also problems with determining not just correlations, but causal relationships.

The main contribution of this article to productivity research is the ability to draw a more rigorous conclusion about the factors that cause and effect engineering productivity. To this end, the authors decide to use an approach called "panel data analysis" (panel). If you explain it on your fingers, these studies collect data over time from the same groups of people or individuals, and then regress. That is, in a broad sense, panel research is synonymous with longitudinal research.

The standard format for performance studies is the use of cross-sectional data (cross-data). If you explain it on your fingers, in such studies, data is collected by observing objects at the same time period. This is usually the easiest thing to do with a survey, but there are problems.

We'll talk about them in next review.

P.S. Interestingly, the results of this study gave rise to a bunch of separate articles on individual topics, many of which were included in the IEEE column about developer proudctivity, about which I am already talking. told. And this column is seen by the co-authors of the article considered in this post:)

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