Why is developer productivity so important?

Debo Ray•August 15, 2022

Developer productivity is about more than lines of code and avoiding burnout. Creating a high-quality software development team is harder than ever. In addition, defining and measuring developer productivity is incredibly hard.

What is Developer Productivity? #

Developer productivity is the field that aims to understand how productive a developer is in any given timeframe/metric/context. It is a key performance indicator (KPI) used by DevOps teams across many industries.

For today’s development teams, boosting developer productivity represents a vital endeavor. Simply put, developer productivity is about the scale of output an individual or team delivers. The faster more new features and capabilities a team can ultimately deliver to end users, the better. To maximize developer productivity, teams need to strike the right balance of speed and quality.

Why Maximizing Developer Productivity is More Important Than Ever #

These days, an organization’s business prospects are increasingly contingent upon its software development prowess. This is true for pretty much any organization in any industry.

As business environments continue to be disrupted, the ability to adapt quickly is essential, whether to respond to evolving customer demands, new business opportunities, competitive threats, or to rapidly iterate on prototypes. In today’s digital age, software plays a vital role in that adaptation.

Whether teams are developing customer facing apps or apps used by internal users, the productivity of development teams is critical. These teams need to quickly and efficiently deliver new apps, services, and capabilities, and ensure code will run smoothly and reliably in production.

Increasingly, business success will be dictated by how long it takes developers to go from concept to getting a product into customers’ hands. However, while speed to market is critical, quality remains vital. If production issues should arise, the hit to consumer trust and user productivity can be increasingly catastrophic for businesses.

Productivity is also key to development teams’ morale. If teams are mired in complexity, constantly stuck waiting for dependencies or in debugging loops, spending inordinate amounts of their day on issues like environment maintenance and fixes, rather than coding, work becomes a grind and developer happiness takes a hit. This poor morale can further erode productivity, not to mention making employee recruitment, onboarding, and retention more difficult.

For all these reasons, maximizing the productivity of development teams is of critical importance for today’s businesses.

Why Maximizing Developer Productivity is More Challenging Than Ever #

In recent years, the makeup of apps has changed fundamentally. The monolithic, static apps of the past have been replaced by modern app architectures, which are distributed, complex, and dynamic. Increasingly, these apps rely on a mix of cloud services, microservices, containerization, serverless approaches, and more. While these modern approaches offer a broad range of benefits, they present development teams with a number of challenges.

Fundamentally, the reliance on local development approaches is becoming a key obstacle, and it represents a model that’s increasingly at odds with the realities of modern app architectures. As a result, teams continue to encounter obstacles in their development workflows, which are placing an increasing strain on team productivity. Following are just a few of the obstacles these local approaches present:

• continuous configuration (network, process/service dependencies, environmental context) drift between local dev envs, production and CI
• heterogeneous set of reasons for slower local build times, which further varies by choice of stack and frameworks
• contextual and environmental mismatches across the fleet of developer machines (build tool performance mismatch, IDE version mismatch, processor architecture mismatch, etc)

High Costs #

Each time a new engineer joins the organization, teams need to invest a significant amount of money and resources to procure a high-powered computer, and to configure it effectively. Further, teams need to continue to invest significant time and effort in keeping these systems current and operational.

Inconsistency and Inefficiency #

Given the inherent characteristics of modern app architectures, it is getting increasingly difficult, if not impossible, to meaningfully replicate modern production environments locally. This is critical because discrepancies between environments breed issues. The more that’s missing from the local system, the more the team is exposed to potential errors. Exacerbating matters is that each developers’ workstation has a distinct set of variables and dependencies. These variable workstation environments make it increasingly difficult for teams to collaborate, and lead to the common, dreaded refrain: “but it works on my machine.” These limitations leave organizations exposed to increasing risks of bugs and other issues.

For all these reasons, teams incur a significant operational burden, and ultimately struggle to speed delivery. As Mike Seavers, VP of Development at Epic Games, revealed, "It currently takes days to onboard new engineers to the team, and the order of days/weeks to get prototypes deployed to production."

Delays and Barriers to Innovation #

Complexity creates administrative overhead, which slows developer output. It is growing increasingly labor intensive for new hires to get their local workstations ready, extending the time it takes for developers to start being productive. As production environments grow more complex, local machine set up and maintenance, for example setting up sandbox environments, continues to grow more time consuming.

On an ongoing basis, teams must allocate a significant amount of effort to keep local environments current, reducing the time they have for productive development work. Because local workstations are unable to replicate external managed services; these local machine-based approaches can stifle teams’ abilities to most fully capitalize on the advantages of these evolving services.

Security Risks #

Having code and data residing on local machines can present a range of security risks. For example, developers may have a number of tools and libraries installed, which can introduce significant risk. While on-device security analysis tools can be added, these tools can be very resource intensive, and introduce a significant performance hit.

As teams move to adopt DevSecOps and zero-trust approaches, secrets, sensitive environmental variables and decentralized workflows present inherent obstacles. The increased reliance of remote and hybrid work arrangements can further expose workstations, sensitive assets, and the business.

How not to measure developer productivity? #

A productivity metric about an engineering team is usually attained by measuring the individual productivity/velocity of every team member (i.e., individual developer performance). The number of hours worked, or lines of code committed or the number of pull requests (PRs) merged are all metrics that get tracked at some point in time or the other - these all seem like good outputs, but are the wrong set of metrics to be tracking for individual performance. I suspect that they are most often tracked due to the low barrier to entry - since they are the easiest to measure; version controls systems like GitHub make it quite easy to track these metrics as well. As soon as we see a few pretty graphs, we ofttimes forget about the overall premise that led us to want to measure developer productivity in the first place.

We all would love to have a single metric we can track, but sadly, I don’t know of one that might exist for this developer productivity.

Software engineering is almost like an art form where measuring the inputs (usually developer salary), and the following subsets of outputs can prove futile, and even hamper productivity. Writing software, especially in the modern tech development process, is getting increasingly complex, having to piece together multiple abstract systems - this makes the trade very sensitive to the programmer’s emotional and mental state.

• Line of code or number of commits written - easily gameable and more code doesn’t really mean that product is getting shipped fast - it’s like measuring a byproduct when we actually care about the result.
• Number of PRs merged - similarly gameable. Am I fixing technical debt in the codebase or actually working on features? If there’s a lot of technical debt, the developer is forced to fix them if they are coming in the way of a shiny new feature.
• Hours worked - being in an office or online responding to Slack messages isn’t really a good indication that someone is working. If a developer likes being in the zone at 1 am, what’s the problem with that? Admittedly, given that it levels the playing field and isn’t super gameable, it’s not as bad as the previous 2 metrics.
• Agile burn charts - this can be a somewhat reasonable (yet super gameable) indication that the work done maps to the number of story points that was committed to, but not much else. Jira makes this pretty easy to achieve, but similar to the GitHub example above, the ease of obtaining this metric doesn’t make it a good indicator of developer productivity.

How can software development productivity be measured? #

A few frameworks have cropped up in the recent past - the most popular being the DORA metrics from Google, and the collaborative effort that gave birth to the SPACE framework. In both of these, the focus lies on understanding the overall time that it takes for a new feature to land in production (i.e., the overall product development time), thus serving customers. This fundamentally requires DevOps support to track a feature through the software development lifecycle (SDLC), right from the time the feature starts to get worked on, as it makes its way through code review, CI, CD, sets of staging environments through to production.

Why does developer productivity feel higher in a startup?

• simplicity of architecture lends itself favorable to build new features
• less technical debt
• clarity of context (and transparency) in why a certain thing needs to get delivered, thus forcing focus towards having well-scoped tasks geared towards delivering value ASAP

Engineering managers need to prioritize the following areas to help and facilitate developers:

• understand impact of technical debt in the source code
• understand the developer experience of the team, and the company
• is the tooling available to the developers slowing them down? What we saw at Uber was that developers complain when things suddenly slow down, but people will get normalized pretty soon and start believing that this is the “new normal” and slow tooling becomes the status quo
• focus on lack of automation around repetitive tasks and investing in productivity tools, that reduce context switching and help speed up the inner loop of software development
• project management that focused on solving core pain points, and having the entire context shared with the development team - we perform better when we have the full context. Transparency wins
• well-planned surveys to gauge Net Promoter Score (NPS) to understand customer satisfaction. Yes, the developers are their customers.

Conclusion #

Boosting developer productivity continues to get more critical to the business. However, the traditional, local workstation-based development approaches of the past are increasingly ill-suited for developing apps that run on modern architectures.

The fragmentation of the SDLC makes it harder to understand team velocity. The truth lies in being able to tie all of these components together, understanding the context and then mapping it back to “how much time does an engineering team deliver good software”, and how can we arm the team to run more efficiently.

DORA’s Four Keys project measures the following:

• Deployment Frequency - How often an organization successfully releases to production?
• Lead Time for Changes - The amount of time it takes a commit to get into production
• Change Failure Rate - The percentage of deployments causing a failure in production
• Time to Restore Service How long it takes an organization to recover from a failure in production?

The SPACE framework helps us understand the following:

• S - Satisfaction and well-being; operates under the fact that productivity and satisfaction are correlated.
• P - Performance; instead of measuring arbitrary byproducts (various outputs), its prudent to measure outcomes. It includes Quality (reliability, number of bugs, etc) and Impact (does the customer like what we built?).
• A - Activity (volume of design and coding activities, builds going through CI/CD, counts of service interruptions etc)
• C - Communication and collaboration
• E - Efficiency and flow

To escape this trap, teams need to start employing development approaches that are fully aligned with modern architectures. The good news is that DevZero can help. DevZero equips teams with cloud development environments that are fast, customizable, and ready to code. Have a look and consider getting started today: devzero.io!

Debo Ray

Co-Founder, CEO