Quality is not slow - speed is not sloppy

· January 8, 2025

I read this LinkedIn Post with great interest (even though it’s the first time I heard about ASPICE).

In particular a sentence at the end at the end caught my attention

it’s about removing friction so engineers can move fast.

I heard the other day that the software that goes into the SpaceX rockets are taken from HEAD of their source control (i.e. Trunk-based development).

In local news, I recently supported a team here in Stockholm to bring the build time down from 2 hours to ten seconds. And at the same time remove a mandatory 6 week regression test period (yes - with “code freeze”) to … 0 days. Releasing from HEAD. With maintained quality. This is not an improvement - it’s a game changer!

There seems to be a mix-up of that control and quality always means going slower. Or that speedy development means that we don’t get quality in process and code.

Nothing can be further from the intention of all the agile practices (test-driven development, DevOps or software teaming / mob programming).

We work that way to increase quality. We reach the quality by iterating fast. We change the way we work, how we code, the frameworks we use etc. to support faster iterations.

There’s no surprise that many of these ideas comes from industries where quality is an absolute requirement (SpaceX, fighter pilots (PDCA loops), Navy seals (Slow is smooth smooth is fast) or emergency health care).

Slowing down delivery to get quality is not an option for these industries. Iterating faster, learn and adapt the way we work to unavoidably get the quality we need is.

But I guess that the rest of us have the money and time to spend on a-spicing, SAFe-ing, or code freezing ourselves to quality.

Twitter, Facebook