The most widely cited number in our industry is one nobody can quite source: engineers spend roughly 35% of their time debugging. The studies behind it range from 1979 mainframe shops to 2023 surveys of FAANG ICs, and the number keeps coming back in the same neighbourhood. Call it a third of every engineering hour.
The math, conservatively
Take a 50-person engineering org at a $180k blended cost. That’s $9M a year in salary. A third of it — $3M — goes to chasing bugs. Halving the time spent debugging is a $1.5M productivity gain, before you count the bugs that ship anyway and become incidents.
| Org size | Annual eng cost | Debugging cost (35%) | Saved at 50% reduction |
|---|---|---|---|
| 10 | $1.8M | $630K | $315K |
| 50 | $9M | $3.15M | $1.58M |
| 250 | $45M | $15.75M | $7.88M |
Why the number doesn’t move
Every wave of tooling — IDEs, linters, type systems, AI autocomplete — promises to cut debugging time. The number stubbornly stays at a third. Our hypothesis: those tools help you write code faster, which means you produce more code, which means you produce more bugs. The denominator scales with the numerator.
The leverage isn’t in writing fewer bugs. It’s in shortening the time between “something is wrong” and “I understand what’s wrong.”
Where the time actually goes
- Reproducing — getting the bug to happen on your machine.
- Localising — narrowing down where in the code it lives.
- Understanding — figuring out why the code behaves that way.
- Fixing — the part everyone thinks debugging is.
Steps 2 and 3 dominate. They’re also the steps where talking it through with someone — duck, colleague, or carefully designed model — produces the biggest measured gains.
What we’re betting on
Quackstack isn’t trying to fix bugs for you. It’s trying to compress steps 2 and 3 from hours to minutes by giving you a partner whose only job is to ask the next useful question. If we move the industry number from 35% to 25%, the math above suggests we’ll have paid for ourselves a few thousand times over.