Half-Baked, Fully Shipped: Thoughts on “Quality” in DX Core 4
Something about the DX Core 4 has been quietly bugging me…
More specifically, about the “Quality” category and how something about it just doesn’t sit right.
And the curious thing is, it’s not wrong! I do believe the key metric (Change Failure Rate) and secondary measures are really useful. But, the framing feels narrow.
Most teams already struggle to define quality clearly. So, bundled up into a single dimension without context flattens a very multi-dimensional concept into just “how often things break after release.”
I get that the DX Core 4 is meant to focus on developer productivity, not product quality or holistic risk. But I also know how metrics like this get used. If “Quality” = CFR in a popular framework, how long before teams start assuming that’s the full story?
I’ve started sketching out what the DX Core 4 categories might look like through a few different lenses (quality-minded, product-minded, and maybe will expand out to others). Early thinking still, but it’s helping me surface some good questions.
