Productivity is a term used to measure the performance of a process where the output from continuous improvement becomes more efficient. The concept began in the manufacturing sector and slowly transitioned to a way of evaluating the work performed by human resources leveraged in any process. Essentially, productivity became a marker to evaluate performance.

Historically, IT has closely followed the concepts and processes of the manufacturing sector. But IT services are different from manufacturing. Ideally, manufacturing produces large quantities of identical, high quality items. While IT strives to produce high quality output, the work product is never the same. Software is in a constant state of change. If the work product is always different, how can a standardized definition of productivity measure varying outputs?

This may explain why the IT sector is still struggling with an effective measure for productivity. To develop a more meaningful definition of developer productivity, companies need to re-examine the true nature of development and what are the ultimate goals.

Developer Productivity Metrics: The Challenges

The IT industry has consistently struggled to objectively define and measure developer performance. The nature of software development inherently presents a few challenges when defining standards. First, there is a strong belief that outcome is more important than intermediary outputs, casting doubt on the need to measure productivity. Second, since no two applications serving the same purpose across an enterprise are similar, baselining is not possible. Third, lines of code, once a common metric of productivity, are no longer applicable as language frameworks have increased technical reusability of code. And to further complicate the issue, no developer has the same pattern of work or deliverables across a week or even 2 days making it impossible to use a baseline for measurement. To be sure, IT teams use processes and tools for baseline workflows, but how these resources are leveraged by the developer community is distinctly individual.

Should Baselining be Used in Developer Productivity?

When measuring performance in other business sectors, the work done on the input to generate the output is close to 100% standard operating procedure (SOP) based. While SOP exists in the IT ecosystem, the role it plays is governing and advisory guidelines for application development. Each individual developer is given the space to improvise, think of an alternate approach, and suggest variations on how the business requirement could be converted to a feature. The code developed goes through continuous changes making knowledge of code behavior key for managing the application. Therefore, developer productivity should not only focus on the application code that is delivered, it should measure the behavior of the developer community that creates and enhances the application. The unique nature of a developer’s work brings up some interesting questions:

1. Is a productivity metric for application development germane to a developer?
2. If the code delivers business features to the end-user and positively impacts the business, is it relevant to look at productivity?
3. No two developers in the IT ecosystem can develop identical executable code, unlike the repeatable manufacturing industry output. Does this negate standard measurement?
4. A developer’s skill and imagination is the biggest asset in the IT ecosystem. Can productivity baselining become counterproductive? Will it impact innovation?

Improve the Outcome of the Entire Software Development Life Cycle

Surprisingly the pandemic has brought clarity and a renewed focus on what makes IT ecosystems different. New data points including developer satisfaction, the kind of team that is managing the code, skill capability, and other issues like cross-skilling are changing how developer productivity is defined. These new focus areas impact the level of productivity of the team and should be factored into a new definition of developer productivity metrics. Many companies are now including these new metrics into the definition of productivity:

• Code maintainability and technical debt including complexity, coupling extensibility, scalability, and similar measures
• Developer association with complex and critical code – reflects the knowledge asset
• Knowledge spread and participation – team vs “individual hero” to leverage the depth of the application expertise (this is becoming more important)
  

These focus areas give engineering managers the ability to look at “developer patterns” concerning the application and find ways to mitigate the risk related to quality and team composition. The focus of productivity should be to get development teams into the “ownership” mindset that leads to delivering well maintainable, effective and efficient features, and promotes the desire to continuously improve. This new perspective means productivity can become one of the key metrics that identifies valuable insights to improve the outcome of the entire software development life cycle and not just the output of a single developer.

Modern Developer Performance Metrics

What makes this approach implementable is the kind of tools already available in the DevOps ecosystem. It has a lot of data points which can guide engineering managers to measure this kind of productivity faster and in an impactful way. The focus should move to prioritize what are the metrics in the IT ecosystem that impacts the business, improves processes, and manages developer’s needs. This gives clarity on the areas that make the biggest impact on ROI. Identifying patterns and trends on these metrics helps to create focus groups, invest in the right automation, improve team structure, and improve skills and cross training. Covid and work from home have brought in mental wellness and satisfaction (or happiness) markers into these metrics.

For those practicing DevOps, there are a variety of measurements that each organization can use to measure business impact and quality. These metrics can be enhanced to include the modern productivity perspective – team and developer patterns.  

Developer inclusive DevOps Metrics 

Measuring impact to business

• Faster time to market
• Release frequency
• Sprint efficiency
• Mean time to deploy/release/rollback

Measuring application quality

• Standard quality and security standards
• Maintainability – covering cohesion, complexity, etc.
• Technical debt

Measuring team (or individual developer) patterns

• Employee satisfaction – especially with hybrid working (work from home) it is critical to measure burnout for sustainable and quality contribution from  developers
• Developer connects to share, unlearn, and learn
• Criticality on contribution to the application, dependency, skill, etc.  

Focusing on productivity is key to objectively look at change and growth of the IT ecosystem. But it is time for companies to modernize the definition of productivity to one that is more focused on impact, not just velocity. Today’s measurement should not be a way to rank individual developers or developer work products but rather the impact to the business and the impact to the entire software development life cycle.