Maximizing Developer Productivity: DORA

In past blogs, I’ve talked a lot about remote teams, finding & hiring remote devs and learning & development. From this week on, we’re going a bit more into the actual development itself. Starting with – your development processes.

When you’re building cars, it’s easy to count the output – the number of cars produced. You can measure defects found during in-factory testing. You can even measure defects found by customers (e.g. those fixed by dealerships under warranty, expensive defects to have).

Building software isn’t like building cars. You can’t simply measure output by measuring lines of code. Some code is written instantly – other bits of code can require so much thought that 10 lines can take an entire day by a highly experienced developer.

When you have a team of local developers, you can see what they’re working on, the progress they’re making – and you can walk by their desks to have a chat. With remote developers, productivity is even harder.

Photo by Lenny Kuhne on Unsplash

Still, in an industry where time is money, optimizing developer productivity cannot be ignored. Let’s dive into a couple of different frameworks, starting with DORA in this article. The framework originated in DevOps. Having worked in many organizations where “Dev” and “Ops” were still fully separated – I’ve become a huge fan of DevOps, not just for startups and scale-ups, or just for SaaS platforms. I’m a huge believer the same frameworks can be applied to and bring enormous benefits to legacy applications in corporates.

History

The DORA framework is rooted in the insights and research conducted by DevOps Research and Assessment (DORA), a firm founded by Dr. Nicole Forsgren, Gene Kim, and Jez Humble. Their research crystallized into a framework that emphasizes not just speed but also stability in software development processes. Every year, DORA publishes the annual “State of DevOps” report. In 2018, DORA was acquired by Google to further enrich its capabilities and reach. Google has continued to publish the annual report, with the last one (covering 2022) announced here.

DORA is by no means the holy grail. It doesn’t allow one to measure individual developer productivity. It does however help organizations compare themselves to others. The DORA framework hinges on four key metrics: Deployment Frequency, Lead Time for Changes, Time to Restore Service, and Change Failure Rate.

Framework

Let’s dive into each of the four metrics of the framework. For each metric, the framework lists the characteristics of Low, Medium and High performance.

1. Deployment Frequency: how often does the organization deploy code. High performing organizations deploy several times a day. Why does that matter? Being able to deploy so often means several things. First and foremost, the smaller the deployment, the smaller the risk of breaking something – and the easier it is to roll back a change if it does. Second, such a high deployment frequency also requires an optimized Continuous Integration / Continuous Delivery (CI/CD) pipeline, which often includes automated code quality checks and regression tests.

2. Lead Time for Changes: how long does it take from code being committed to code being deployed to production.

3. Time to Restore Service: Gauges the resilience of the system by calculating recovery time post an outage or failed deployment.

4. Change Failure Rate: the percentage of unsuccessful changes, how many deployments to production result in degraded service, requiring a fix. As QA engineers will frequently tell you – the sooner you find a defect, the less expensive it is. Defects found during coding or initial tests require rework, but that’s it. Unsuccessful changes impacting end users often see lots of different people scrambling and getting involved to fix the issue as soon as possible.

Source: Google. 2022 Accelerate State of DevOps Report.
https://cloud.google.com/devops/state-of-devops/

In this last report, the team have divided up the respondents (33,000!) to the survey into four different clusters, from Starting and Flowing (which both speak for themselves) to Slowing (less frequent deployments, high stability) to Retiring (maintaining, but no longer developing). They’ve also added their views on Reliability (availability, latency, performance, and scalability) in this year’s report.

What’s next?

So, knowing all this, where do you start? First of all – read the report, front to back. It comes with so much advice on how to improve, from organizational culture to SRE’s and tooling. Then, start measuring, put a dot on the horizon – and create a plan.

Interesting in discussing this further? Reach out – and let’s talk!