[1/2] Measuring Engineering Productivity (from Software Engineering at Google) (Category Productivity)

While I'm on vacation. familiarize with a cool book from Google engineers, where they're opening the veil of secrecy about their engineering culture, processes and practices. I love this book and decided to share a topical chapter on how Google approaches measuring engineering productivity and here are the main thoughts from this chapter. Google is a data-driven company where decisions are made based on objective information, not subjective opinions. With business growth, the engineering team also grows, but if the organization grows conditionally linearly, then communication costs grow quadratically. (You can remember the number of ribs in the full graph - n * (n-1) / 2). So we can't just scale an organization linearly -- we can make every engineer more productive. To increase productivity, you need to be able to find inefficiencies in engineering processes and fix the problems found. To do this, Google has assembled a separate team of researchers studying engineering productivity. This team has both engineers and social scientists from a variety of fields, including cognitive psychology and behavioral economics. Scientists study the human side of engineering processes This team is very sensitive to the topics of their research - you can measure a lot, but first you need to answer the question, and whether it is worth measuring. And they have a special process for triage. (triage)where they ask questions to teams that have come to them with a research request -- What result are you expecting, and why? This question allows you to understand the initial biases and take them into account when assessing the experiment. -- If the data supports your expected result, what action will be taken? It makes sense to measure something if it leads to decisions and actions. n -- If we get a negative result, will appropriate action be taken? If the negative result of the study does not affect the decision, then it is also not necessary to conduct research. -- Who is going to decide to take action on the result, and when would they do it? We need to know who the LPR is. (decision-maker) and whether it is relevant to the study order. It is necessary to understand what approaches to research this LPR considers valid - it needs quantitative data, qualitative data. (interview)He trusts the results of surveys or trusts only the data from the logs of systems. (activity based stats). In general, this is a series of tips that you need to know your audience and their needs:) If you ask these questions in time, then many measurements are simply not worth it, for example, the authors give such examples.

• You can't afford to change the process/tools right now
• Any results will soon be invalidated by other factors
• The results will be used only as vanity metrics to support something you were going to do anyway
• The only metrics available are not precise enough to measure the problem and can be confirmed by other factors The authors talk about their approach to GSM. (goals - signals - metrics) for Goal is the expected end result, it is formulated in high-level terms and does not contain references to how to measure it. Signal is how you understand that the result is achieved. You want to measure it, but it’s not always easy.

• Metric is a proxy for the signal. It's something we can actually measure, maybe it's not a perfect signal measurement, but it's close enough.

As an example of the study, the authors say about the readability review process, which is adopted by Google. In fact, this is an approach to ensure that the codebase has a uniform style and appearance. This process comes from the early years of Google and resembles the usual code review, but the focus is not on the semantics of changes, but on the idiomatic use of code. The study was decided to conduct because it was believed that modern linters and static analyzers can produce good results without involving people. Continuation will be in next post.

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes