Pick two?
There’s an old engineering line: good, fast, cheap — pick two. It’s useful for scoping a project. It’s also quietly responsible for a lot of bad software, because somewhere along the way teams adopted a deeper, wronger version of it: that quality and speed are opposites. Slow down to do it right, or move fast and clean it up later.
We named this firm around the opposite belief. High quality is not the tax you pay for speed. It is the engine of it. That’s not a motivational poster — it’s one of the better-supported findings in our field.
The tradeoff is a myth
The most rigorous look at how software actually gets delivered is the DORA research program: years of data across tens of thousands of teams, summarized in Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim. Its headline finding is blunt — speed and stability are not a tradeoff. The elite teams deploy far more often and fail far less. The very practices that make delivery fast — small changes, automated testing, fast feedback — are the ones that make it reliable.
Read that again, because it dismantles the premise. The fastest teams aren’t fast despite caring about quality. They’re fast because they do.
Where the time actually goes
When you skip quality to “save time,” the time doesn’t vanish. It moves — to the most expensive place possible: later.
The numbers are sobering. CISQ put the cost of poor software quality in the U.S. at roughly $2.41 trillion in 2022, including about $1.52 trillion in accumulated technical debt — the compounding interest on every corner ever cut. And it’s no longer just an engineering line item. In an MIT Sloan Management Review article on technical debt, an Accenture survey of more than 1,000 C-level executives found 70% say technical debt severely limits their ability to innovate, and 69% say it makes their IT function much less responsive to the market.
That’s the part that gets lost: cutting quality feels fast in the sprint and is catastrophically slow over the quarter. You don’t get the time back. You pay it, with interest, in rework.
None of this is new
The idea is forty years old and keeps getting rediscovered. W. Edwards Deming described the “chain reaction” in Out of the Crisis (MIT, 1986): improve quality, and costs fall because there’s less rework and fewer mistakes; productivity rises; you capture the market. Philip Crosby put it on a book cover — Quality Is Free. The savings from not doing it twice more than pay for doing it right once.
Software relearns this lesson on a loop, because the shortcut is always right there, and the bill always arrives after the demo.
What “quality makes you fast” looks like
A lot of our work is rescuing projects that chose speed over quality and got neither. On the ground, fast and good turn out to look identical:
- Fix causes, not symptoms. A patched symptom comes back; a fixed cause is gone. Chasing symptoms is the treadmill that makes a troubled project feel busy and stay stuck.
- Small changes. Smaller increments are both faster to ship and less likely to break — the rare free lunch DORA keeps confirming.
- Tests you trust. A good test suite isn’t bureaucracy. It’s the thing that lets a senior engineer change scary code on a Friday and go home calm.
- Senior people, the first time. Most “we’ll fix it later” debt is incurred by people who didn’t yet know what right looked like. Experience is just a lot of expensive mistakes you don’t have to repeat.
The catch
None of this argues for gold-plating. Quality isn’t polishing code no user will ever feel, and zero technical debt is not the goal — MIT Sloan’s own guidance is that some debt is a deliberate, sensible bet. The discipline is knowing the difference: where to move fast and loose, and where the work is too important to get wrong.
That judgment — not perfectionism — is what actually ships software quickly.
Quality. Fast.
It reads like we picked two of three and got greedy. We didn’t. It’s a claim about cause and effect: over any horizon longer than a single sprint, quality is the thing that makes you fast. The teams that ship quickest are, almost without exception, the ones who refused to ship junk.
Sources & further reading
- N. Forsgren, J. Humble, G. Kim, Accelerate / the DORA program — dora.dev
- CISQ, The Cost of Poor Software Quality in the U.S.: 2022 Report (Herb Krasner) — it-cisq.org
- MIT Sloan Management Review, Technical Debt Might Be Hindering Your Digital Transformation — sloanreview.mit.edu
- W.E. Deming, Out of the Crisis (MIT, 1986); P. Crosby, Quality Is Free (1979)
Facing this yourself? See our related service →