HomeDevelopmentDeveloper Productivity Needs to Become More Important DevOps Metric

Developer Productivity Needs to Become More Important DevOps Metric

There’s a lot of focus on developer productivity these days largely because as organizations realize how dependent they are on software to drive revenue and improve profitability the pace at which software is developed is now having a much greater material impact on the business.

The challenge is that most DevOps teams have in recent years been obsessing about metrics that have little to do with developer productivity. The DevOps Research and Assessment (DORA) metrics that Google is now the custodian of focus more deployment frequency and mean time to recovery than they do on how productive developers are.

Unfortunately, measuring developer productivity is an inexact science. Once upon a time an organization might have tracked the lines of code being written but the total number of lines of code written may not be especially good. In more recent times, metrics have been developed that among other things keep track of how much time developers spend actually coding versus maintaining their software development environment.

For example, a team of Microsoft researchers have developed a DevEx framework for gaining insights into the developer experience within an organization by measuring the flow of work, the feedback loops and the overall amount of cognitive load placed on developers to create a set of key performance indicators.

The issue that most IT leaders will immediately encounter when considering that approach is how much the whole shift left movement makes achieving any of these KPIs problematic. In recent years more responsibility for managing infrastructure and cybersecurity has been shifted toward developers. Every minute developers spend on these tasks, however, is in theory one less minute they are spending writing the business logic that drives an application.

Of course, there’s no way developers are going to be write business logic for eight hours straight every day so there are maintenance windows. However, application development is as much art as it is science. No one knows for sure when inspiration might strike but if developers are busy maintaining code that they created to provision infrastructure the less probable it become for some flash of brilliant insight into how an application might be made better is likely to occur.

In fact, many organizations are now trying to strike a more nuanced DevOps balance to lighten the cognitive load of developers by embracing platform engineering. Essentially a more centralized approach to managing DevOps workflows, the hope is that if a set of processes are managed in a consistent fashion developers should have more time to be creative. The added benefit is that because most developers are not all that adept at securely provisioning infrastructure and deploy applications that approach will also reduce the number of misconfigurations and vulnerabilities that today are the bane of application security.

Naturally, there is always going to be a danger of overreach. Developers like to be able to experiment with new tools and platform so any approach to platform engineering that smacks of totalitarianism will be resisted so IT leaders need to proceed with caution. If talented developers start heading for the exits, IT leaders will find it difficult to replace them because great developers even in an economic downturn are still difficult to hire and retain.

IT leader, however, can’t let the inmates to take over the proverbial asylum either. One of the reasons securing software supply chains has become so problematic is the simple fact that each development team as over the years defined their own unique set of DevOps workflows with often too little regard for best practices. Making developers happy is important but not to the point where application development and deployment becomes hopelessly inefficient.


Receive our top stories directly in your inbox!

Sign up for our Newsletters