Three frameworks for three different questions
| DORA | SPACE | CODA | |
|---|---|---|---|
| The question | How fast and how reliably do changes reach production? | How productive are developers, and how are they doing? | Does the team make sound decisions and understand the code it ships? |
| What it measures | Five delivery metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate, deployment rework rate | Five dimensions: satisfaction and well-being, performance, activity, communication and collaboration, efficiency and flow | Four dimensions in two pairs: Decision Velocity and Decision Confidence, Comprehension Ratio and Review Depth |
| The data | The delivery pipeline and the incident records | System data, plus at least one perceptual measure, such as a survey | Decision records, pull requests, code reviews and conversations with developers |
| Measured for | An application or a service | An individual, a team or a system | A team |
| Status | A research programme since 2014, rework rate joined the model in 2024 | Published in ACM Queue in 2021 | A hypothesis, version 0.1, not yet run as a measurement |
DORA sees delivery, not understanding
DORA measures outcomes, and its metrics keep each other honest: optimize for deployment frequency at any cost, and the change fail rate gets worse. The data comes from the pipeline and the incident log, so it’s cheap to collect and hard to argue with.
Its blind spot is everything that happens before a failure. A team can ship code nobody understands, and the metrics stay green until that code breaks. Then the change fail rate and the recovery time move, but by then the cost is already paid, in an incident nobody can debug.
SPACE sees the developers, and AI inflates part of it
SPACE’s authors argue that no single number captures productivity, and they ask for metrics from several dimensions, at least one of them perceptual. That makes SPACE good at catching what DORA can’t: burnout, friction, a tool rollout that feels slower than it was promised to be.
AI coding tools strain two of its dimensions. Activity counts, such as commits and pull requests, rise when AI writes more of the code, whether or not anyone understands that code. Satisfaction can rise too, because the tools take over tedious work. The authors already warned against reading activity on its own, but neither dimension asks whether a developer can explain a change they shipped. SPACE was designed in 2021, before that question became urgent.
CODA adds judgment, but it’s unproven
CODA proposes to measure the judgment underneath both: how quickly a team decides, how well its decisions hold up, whether developers understand the code they ship, and how thoroughly code gets reviewed. Comprehension Ratio has no counterpart in DORA or SPACE.
The price is effort and uncertainty. Some of the signals come from conversations, not dashboards, so CODA costs the team time. And it’s a hypothesis: it hasn’t been run as a measurement yet. The CODA paper describes the four dimensions and what would prove the model wrong.
Start with the question you can’t answer
- You don’t know how fast and how safely you ship: start with DORA. The pipeline and the incident log have the data.
- Delivery looks fine, but people are tired, or a new tool hasn’t paid off: add SPACE, with a survey next to the system data.
- AI writes a growing share of your code, and nobody can say whether the team still understands it: that’s the question CODA is built for.
The three don’t replace each other. DORA measures the outcome, SPACE and CODA help explain it.