Looking back on 2023, two key themes underlaid much of what drove the new tools and technologies across the entire development ecosystem. One was artificial intelligence, both using and building it, and the other was making developers more productive.
That last one was perhaps the hardest to quantify and describe. For one thing, developer productivity came in many forms, from new design patterns and practices that simplified cloud-native and mobile development, to tools that codified years of experience, providing ways for different engineering disciplines to collaborate and deliver consistent results.
Some of productivity’s prominence may have come from the rough economic waters that drove engineering teams to deliver more with less. Other reasons included the ongoing “app gap” and a growing need to deliver cross-platform solutions. The result is a more mature approach to engineering, treating it more as a science and less as an art.
Measuring productivity
A focus on productivity demands that we answer the key questions: What is productivity? How do we measure it? We all know the apocryphal stories of companies that measure developer productivity by either the number of lines of code written or the number of bugs fixed, and how these metrics fail to deliver the expected results (or how engineers game them to their own benefit).
For one thing, developer productivity mixes tangible and intangible conditions. What do we know about how well a project was defined, or if there were personal conflicts inside a team? And perhaps more important, are those developers actually happy?
That all adds up to a big issue. How can we track developer productivity, and can we do it without affecting that productivity by adding more stress to developers?
Linking in to developer productivity and happiness
Microsoft subsidiary LinkedIn has been thinking about these issues a lot. LinkedIn is a big and complex online service, wrapping a whole host of features under the skin of its web application. Those features include the community platform that brings users to LinkedIn and the training and recruitment products that make a profit.
All are important, and all need to work together to deliver the service LinkedIn users and customers expect. That delivery requires a lot of developer effort, from the infrastructure to the myriad of services and microservices that come together to form a modern social network.
LinkedIn is the product of its developers, and the company needs to keep them productive and happy. So, it needs to understand what those two key requirements mean to it as an organization. Building on its own experiences and those of other organizations, including Mozilla, it’s been putting together and implementing a Developer Productivity and Happiness (DPH) Framework that provides guidelines for measuring its own development processes.
The resulting guidelines have proved useful, and they’ve recently been open sourced so other businesses can learn the same lessons and improve their own development processes, understanding what makes them work and where bottlenecks and frustrations might lie.
Changing development methods require changing management
One important part of the LinkedIn DPH Framework is understanding the way software development has evolved. We’ve always understood that build times need to be factored into any productivity metric, but the shift from waterfall to agile and CI/CD (continuous integration and continuous delivery) has changed that. Now every code push can result in a build, with the automated tests that are part of the process. We also need to consider code reviews, the time taken testing and processing pull requests before accepting changes.
Many of the metrics LinkedIn uses come out of the tools themselves, whether it’s the performance of a local toolchain on a developer PC or a cloud-hosted CI/CD platform. The intent is to find blockers and choke points that get in the way of delivering code and to make sure that users have the best experience possible.
That new model does require new ways of working. Developers can’t deliver huge blocks of code anymore, as they’ll be left waiting for a review to complete. And code reviewers can’t let a backlog develop. Using DPH metrics, we can work out what makes both sides’ work easier to complete. That may result in more frequent but smaller submissions that are easier to understand, easier to test, and quicker to approve—making code easier to maintain and understand.
The resulting benefits are clear: Developers, both junior and senior, get to stay focused on their code, avoiding distractions that require time to overcome.
From numbers to results
It’s all very good having a framework to determine developer productivity and define the metrics used, but how can we turn that data into action? One key element is having some form of dashboard or portal to display the data and apply statistical significance. LinkedIn has built what it calls a Developer Insights Hub around DPH, making it easy to see key data, such as the median wait time for a build to complete, along with any outliers.
Having this information can then encourage changes. If the median build time is too high, can the internal developer tools team improve compiler and linker performance? If it takes too long to approve a pull request, can developers change how they build and submit commits? There’s a lot of opportunity here, as measurements make it possible to understand not only what’s happening now, but how it compares to the past.
That lets us understand how projects of similar complexity run, giving us more information to feed into other parts of the development life cycle. Armed with knowledge of developer productivity trends, developer leads, program managers, and project planners can make more accurate decisions around resourcing and project timelines, ensuring that management is better informed. With projects that aren’t tied to needlessly ambitious schedules, developers will be able to balance work and life more effectively, increasing their happiness and improving their productivity while still delivering quality code.
Next steps: building out to other organizations
Open sourcing a framework like this is an important step. It allows organizations to determine what signals and metrics work for them and share insights and lessons with a wider community. If there’s one thing missing from LinkedIn’s release, it’s a formal DPH community.
Having a cross-industry community working on DPH metrics is important. It allows organizations to benchmark metrics and provides an open forum for discussing how developer productivity and happiness are related. No two organizations are the same, and how and what they measure will be different. However, they can use similar dashboards with a common understanding of the statistical nature of their metrics.
In talking about this announcement with LinkedIn, I kept coming back to the adoption of observability as a way to understand how cloud-native microservice applications operate. This work has very much the same feel as those early observability papers, giving us much-needed insights into how we build code and how we can improve the development process to the benefit of both the user and the developer.