Measuring developer productivity

Few months back, I had a chat with a former colleague and friend of mine about developer productivity. Over the last 15 years, we had multiple intense discussions about developer productivity, ways to measure and improve it at various stages of our career. My views on this topic have evolved a lot over these years. Here is a summary of our discussion and my extended thoughts.

• Focus on team productivity over individual productivity.
• Adopt the four key metrics model (Refer Accelerate by Jez Humble), you don't need to measure anything else. These are Frequent code deployments, Faster lead time from commit to deploy, Faster mean time to recover from downtime, and Lower change failure rate.
• Focus on measuring business goals, instead of handover between teams. Success of a subteam on a particular metric does not mean anything to business. Refer Agile IT Organization Design by Sriram Narayan for more on this.
• Productivity can be improved by short cycles and quick feedback, this includes things like code review, unit testing, A/B testing etc.  
• Avoid measuring productivity with "lines of code checked in" or scrum burn-down charts.
• All the ranks within your organization should be aware of business goals, and how those goals are measured.
• These days various tools and frameworks related to distributed tracing, telemetry, and infrastructure observability are getting adopted. Most of these implementations are focused on technical request tracing, and monitoring. There is a strong need to integrate business monitoring via these tools. For example, an operations team monitoring an order taking application and supporting infrastructure using Grafana Dashboard, should also have a widget indicating “number of successful order placed”, and a rule triggering a pager to the company's marketing team if it falls below a certain average. (kind of an extreme example, but hope you will get the idea).

As a leader, we need to "Make it easy to do the right thing, and make it difficult/(or near impossible) to do the wrong things”. This is easier said than done. I will give two examples here.

1. A project had a wired build setup, which required modification to multiple large build configuration files every time you add a new file. Developers preferred adding code to existing file/class, just to avoid that pain, which impacted code cohesion and modularity. A simple tool to automatically generate build configuration files solved that problem, and made it easy to do the right thing.
2. Another project I worked relied on hundreds of XML files, and an ill-formed XML file used to break things without any warning. Integrating an XML validator as part of the gated checkin process solved that problem, and made it difficult to do wrong things.

These things look obvious on retrospection, but many teams suffer a loss of productivity on day to day basics due to similar issues.

Thanks for reading, hope you found this insightful.