[Software Engineering at Google] CH7 Measuring Engineering Productivity
1 minute read
Why Should We Measure Engineering Productivity?
We could make each individual more productive
Conclusion
At Google, we’ve found that staffing a team of engineering productivity specialists(e.g. cognitive psychologists) has widespread benefits to software engineering; rather than relying on each team to chart its own course to increase productivity, a centralized team can focus on broadbased solutions to complex problems
Such “human-based” factors are notoriously difficult to measure, and it is important for experts to understand the data being analyzed given that many of the trade-offs involved in changing engineering processes are difficult to measure accurately and often have unintended consequences
TL;DR
Before measuring productivity, ask whether the result is actionable, regardless of whether the result is positive or negative. If you can’t do anything with the result, it is likely not worth measuring
Select meaningful metrics using the GSM framework. A good metric is a reasonable proxy to the signal you’re trying to measure, and it is traceable back to your original goals
Select metrics that cover all parts of productivity (QUANTS). By doing this, you ensure that you aren’t improving one aspect of productivity (like developer velocity) at the cost of another (like code quality)
Qualitative metrics are metrics, too! Consider having a survey mechanism for tracking longitudinal metrics about engineers’ beliefs. Qualitative metrics should also align with the quantitative metrics; if they do not, it is likely the quantitative
metrics that are incorrect
Aim to create recommendations that are built into the developer workflow and incentive structures. Even though it is sometimes necessary to recommend additional training or documentation, change is more likely to occur if it is built into the developer’s daily habits.
