What is developer productivity?
Developer productivity attempts to transfer the concept of production efficiency to software development. Productivity is commonly used in industries with a clear relationship between inputs, outputs, and outcomes. You would expect to see a corresponding change in the downstream metrics by increasing inputs. For example, increasing materials and labor in a factory will increase the number of products created (output), generating an increase in revenue (outcome).
The relationship between inputs and outputs is less direct in software delivery. Adding more code and features to a software product doesn’t guarantee increased value to users or an increased marketplace for the product; it might reduce the software’s value by making it more complicated to use and more costly to maintain.
Developer productivity isn’t about coding speed but the team’s ability to deliver value to their users. Development team performance is influenced by many factors, including skill level, tool choices, task complexity, process, flow of information, and organizational culture. Each of these factors can suppress or amplify the others. While it’s easy to count features, pull requests, or lines of code, it’s far harder to assess collaboration, knowledge, or creativity and innovation, and these are more important.
This is part of a series of articles about developer experience.
Challenges in measuring developer productivity
Developer productivity is an area filled with hazards. Even with good intentions, you’re likely to trigger a cascade of unintended consequences and behavior changes based on the measurement system you design. Traditional metrics like lines of code or the number of commits do not adequately capture the value and quality of contributions. They can even be misleading, as they might incentivize outputs over outcomes.
Quantifying creative work
Quantifying creative work in software development is difficult. Developers don’t just write code; they engage in creative problem-solving that depends on building a deep understanding of the software’s users. This is crucial for creating innovative and valuable solutions. Unlike physical tasks that can be easily counted or timed, creative tasks vary significantly in time and effort required, often depending on the complexity of the problem and the developer’s experience and intuition.
Moreover, assessing creativity involves subjective judgment, making standard quantification complex. The quality and impact of a creative solution can vary, as can the effort required to arrive at it. You must rely on indirect indicators of creativity, such as peer reviews, user feedback, and achieved outcomes, rather than direct scores or counts.
Crucial but invisible work
Many tasks don’t directly contribute lines of code to the software but have been found in industry research to drive high-performing teams and organizations. Tasks like providing feedback on designs, helping unblock team members, onboarding new developers, and updating developer documentation are all invisible glue work, without which your team’s performance will suffer.
Assessing productivity without taking glue work into account discourages people from doing it or limits career opportunities for those doing some of your team’s most crucial work, making it more likely you’ll lose these valuable developers.
Diverse workflows and technologies
Software developers interact with a range of technical infrastructure. Different programming languages, frameworks, architectures, and tools present learning curves and potentially constrain productivity. The skills and knowledge needed to work on a legacy system can vastly differ from those needed for newer technologies.
Just as the technical infrastructure can influence productivity, the process developers use, such as agile, lean, or DevOps, has a considerable impact. Teams optimizing for adaptability will perform differently from those optimized for throughput. The metrics you use to measure a team must align with these different process goals.
Thinking long-term
You can accelerate many software development metrics in the short term by ignoring the long-term consequences. For example, you can finish a feature faster if you skip test automation or avoid improving the design of the code. The effort to maintain the software will eventually become economically unsustainable, but the effects are felt too late.
You need to factor in the software’s sustainability, which can easily be harmed by measurement systems that elevate the importance of short-term goals. Whenever you introduce a metric, it’s useful to ask yourself what negative changes it might cause.
Key Developer Productivity Metrics
You must approach measurement with caution and understand your metrics don’t capture the whole story. A good measurement system combines a strong set of outcome metrics with a number of leading indicators whose relationship to the outcomes you validate over time. As throughput and stability are linked to organizational goal attainment, these are a good place to start.
Below are key metrics commonly used to assess developer productivity:
- Goal-based outcomes: While the organization has goals, it’s best to create product goals that can be influenced entirely by feature development, such as “a shopping basket abandonment rate below 20%”.
- Lead time for changes: Measures the time it takes a change to move from development-complete to deployed to production.
- Deployment frequency: Tracks how often production deployments occur.
- Change failure rate: Measures what percentage of changes result in a service-impacting issue.
- Recovery time: How long it takes you to recover from a deployment that caused a service-impacting issue.
- Developer satisfaction: Measures developer well-being and provides an early signal of problems before they impact software delivery performance.
- Cycle time: Measures a sub-process within software delivery, such as the time from when work starts on a feature to its commit to the main branch.
- Build time: Measures the time it takes for a full build of the software, along with the initial set of automated tests.
- Collaboration metrics: Evaluates team dynamics using indicators like code review frequency, pull request merge times, and contributions to developer documentation.
When using these metrics, it’s essential to consider the broader context and avoid incentivizing behavior that might undermine long-term sustainability. Combining these metrics allows organizations to signal there’s a balance to be struck, for example, making clear that stability is as important as throughput.
Tony Kelly is a DevOps marketing leader who drives innovation and awareness of the latest trends in Continuous Delivery.
Frameworks and metrics for measuring developer productivity
Here are several popular frameworks designed to capture both qualitative and quantitative aspects of development work.
DORA metrics
DORA metrics provide a reliable way to measure software delivery performance. There are 4 key metrics: deployment frequency, lead time for changes, time to recover after a failed deployment, and change failure rate. These metrics offer insights into the speed and resilience of software delivery, highlighting areas for improvement. High-performing teams deploy small batches often, maintain stability, and recover quickly when there’s a problem..
You can use DORA metrics to highlight improvement opportunities, and they naturally encourage both small batches and automated deployment pipelines. Using the DORA metrics as part of your continuous improvement process also improves developer experience, as developers can progress their changes more easily and safely to staging and production environments. Improvements to your deployment pipeline help you increase the efficiency of deployment pipelines and help you build trust with other business units through reliable deployments.
DevEx metrics
Although DevEx metrics measure developer experience, they often prove to be leading indicators of productivity. Developers are happier when they can get their changes to production smoothly and obtain timely feedback about features and enhancements. DevEx metrics measure perceptions and workflows across the dimensions of feedback loops, cognitive load, and flow state.
Improving how developers think and feel about their work increases productivity and you will identify improvement opportunities by collecting DevEx metrics. It’s important to minimize the effort of obtaining these metrics and avoid causing survey fatigue where you depend on qualitative input from developers.
SPACE framework
The SPACE framework is a flexible model for measuring developer productivity across five dimensions: satisfaction and well-being, performance, activity, communication, and efficiency. It goes beyond code quantity and considers factors like work environment and communication, providing a more holistic view of productivity. Satisfaction is vital, as happy developers tend to be more innovative and less prone to burnout.
Performance and efficiency address the speed and quality of deliverables, while activity analyzes the volume and nature of developer contributions. Communication evaluates collaborative efforts, which is essential for team success. You can use the SPACE framework to gain a nuanced understanding of productivity that helps align team efforts with strategic goals while supporting a positive work culture.
Developer thriving framework
The developer thriving framework focuses on creating the right environment for developers to be productive. The framework creates a virtuous cycle by improving autonomy and self-belief while nurturing a learning and supportive culture. Developers operating in the right environment can contribute more to their teams, especially in crucial areas such as creativity and innovation.
The framework recognizes that personal growth and job satisfaction are as crucial as technical skills. It uses factors that influence productivity in ways that uplift the desired cultural outcomes. This prevents a fixation on surface definitions of productivity and resolves the problem of complex metric systems.
Impact metrics
Impact metrics are outcome-focused and linked to desired organizational outcomes. Converting an overarching goal into one that the software can influence lets teams own the outcome. They can try ideas and discover their impact on the intended outcome, pivot to new ideas where changes don’t work out, or close a goal and move to the next one when they reach the intended result.
These metrics work well with the impact mapping technique, which can help teams generate experiment options and test assumptions. The approach goes beyond goal attainment by building institutional knowledge about the industry and its customers.
The impact goals for a retail website might focus on conversion rates, basket value, and checkout completion rates. Working against impact goals means you know when to try a different approach and when to move on to a new goal. Crucially, it helps you identify features you should remove as they don’t positively impact the goal.
Best practices for improving developer productivity
Start with psychological safety
The prerequisite for developer productivity is psychological safety. If the team can’t take risks without feeling insecure or embarrassed, they will always depend on double-checking each small move with others. This prevents them from achieving productivity gains as the fastest they can deliver features is the speed of approval to try an idea.
Other factors that work alongside psychological safety are dependability (being able to count on each other to do high-quality work on time), clarity (goals, roles, and plans are clear), meaning (feeling that you’re working on something personally important), and impact (believing your work is important). These factors are a stronger indicator of high-performing teams than any other factor.
Foster a learning culture
Creating a culture of learning is essential to productive teams. The scope of a learning culture is broad, encouraging teams to stay up-to-date with technological advancements and modern software delivery methods and sharing skills and practices. A learning culture also extends to learning the organization’s industry and building a deep understanding of users and their needs.
To foster this culture, you can provide training programs, workshops, brown-bag sessions, and access to learning resources. The most important thing you can do is provide time for developers to learn. A deep understanding of users is best developed through direct contact between the developers and those who use the software.
Increase developer autonomy
Context, autonomy, and trust are necessary to create motivated developers. Developers should be allowed to make decisions about tools, processes, and problem-solving approaches to continuously improve their productivity and efficiency. You can place guardrails around decision-making by allowing developers to choose from a set of options or by providing them with the conditions for self-direction and those for escalation.
Developers are more engaged and motivated to succeed when they are involved in decisions and goal setting. Providing desired outcomes instead of lists of features allows development teams to experiment and iterate on solutions, which increases their responsibility and commitment.
Continuously improve development processes
Your development and software delivery processes are never perfect, but they can be continuously updated and improved. Lead and cycle times can identify bottlenecks that teams can fix to improve the flow of work. Removing unnecessary tasks and meetings, using automation, and optimizing for flow can help keep the focus on delivering value.
To inspire improvement, you can draw from agile, lean, Continuous Delivery, and DevOps. For the best results, you need a mix of work management, technical practices, and cultural capabilities. Agile encourages responsiveness to change, and lean principles seek to identify constraints and eliminate waste in the work system. Continuous Delivery provides a set of concrete technical practices and DevOps combines these with a collaborative culture and shared goals.
Invest in high-quality documentation
Developer documentation is a crucial yet overlooked factor in improving developer productivity. High-quality documentation is reliable, easy to find, and updated as changes occur. When documentation meets these requirements, developers will use it to unblock themselves. Without it, they have to find someone to help them.
When developer documentation depends on volunteer contributions, it often ends up being maintained by a single developer. Ironically, traditional management views this maintainer as a low performer because they will spend less time on features. The reality is that high-quality developer documentation amplifies technical practices to create the highest-performing teams. It is an effective strategy to keep documentation lightweight and encourage all team members to review and update it when they make a change that impacts it.
Prioritize code quality and maintainability
Protecting the ability to deliver software at a sustainable pace over the long term means paying constant attention to code quality and maintainability. High-quality code is easier to read, understand, and modify, which happens more often than writing a module from scratch. That means keeping a low tolerance for technical debt and inconsistencies, using automated tests to make refactoring easier and safer and identifying when a component needs to be improved to make it easier to change.
Dedicating time during feature development to maintaining and improving the code quality will result in a larger proportion of time being spent on feature development instead of debugging. Static code analysis and linting tools help maintain code quality and consistency and often provide machine-assisted corrections that speed the process of improving the code. Focusing on maintainability means developers create software they can easily adapt to future needs.
Improve developer productivity with Octopus
Developers want to solve problems and are happier when they can be productive. To achieve a flow state, they need frequent, high-quality feedback loops, manageable cognitive load, and substantial focus time. When developers experience friction, it’s a sign that they can’t deliver as much value as they feel they could.
The CD pipeline is the element of their workflow that has the biggest influence on these factors. Deployment automation improves the DORA 4 keys and impacts all 3 DevEx dimensions of feedback, flow, and cognitive load.
Octopus significantly impacts software delivery performance, increasing deployment frequency while reducing deployment-related failures. You can also provide self-service deployments and runbooks for developers so they don’t have to raise tickets for deployments or day-2 operations tasks, further boosting productivity and performance.
Find out more or start a trial to see how it works.
Help us continuously improve
Please let us know if you have any feedback about this page.
