Technical debt vs. change delivery capacity
A simulator for comparing how refactoring and structural choices affect your ability to deliver change over time.
Each change adds surface area. Technical debt makes that surface area harder to change next time.
This simulator is designed to compare scenarios, not forecast outcomes. The absolute numbers matter less than how different strategies change the trajectory.
Change delivery capacity, debt drag, and technical debt over time
As systems grow, technical debt and uncertainty absorb a larger share of effort unless actively reduced, limiting how much new functionality can be delivered per unit of effort.
System outcomes
Simulator scope
This simulator assumes fixed effort, constant demand, and smooth system growth. It does not account for rewrites, organizational change, morale effects, or market timing.
Operational incidents and firefighting are not modeled directly; their impact is represented indirectly through increased uncertainty and reduced change capacity (i.e., higher effective technical debt).
What this simulator does NOT claim
- This does not predict actual delivery dates
- This does not claim a universal debt growth rate
- This does not measure developer performance
- This does not model organizational change, morale, or market effects
- This does not imply refactoring alone fixes systemic issues
- This does not model value realization or market impact of changes
Frequently asked questions
What is technical debt in this model?
Technical debt represents structural complexity and uncertainty that makes each new change harder to implement, test, and integrate. It is modeled as a latent burden that amplifies delivery drag over time if not reduced.
Why does delivery slow even when teams work just as hard?
Because a growing share of effort is absorbed by technical debt drag. The simulator separates effort applied from effective change delivered to show how capacity erodes without visible idleness.
Does technical debt grow just because time passes?
Debt compounds through interaction with change, not through the passage of time alone.
Why is the debt impact non-linear?
Empirical studies and practitioner reports consistently describe threshold effects where delivery slows suddenly rather than gradually. The simulator models this acceleration explicitly to reflect real-world behavior, even though the exact curve shape varies by system.
Why can't refactoring eliminate all drag?
Refactoring reduces accumulated debt but does not remove structural constraints such as architecture, tooling, coordination paths, or observability gaps. Eliminating baseline drag requires systemic changes, not just cleanup.
What kinds of practices reduce baseline drag?
Practices that change how work flows through the system—such as improved observability, modular architecture, trunk-based development, and platform simplification—can reduce baseline drag. Cleanup alone cannot.
Is the exponential growth assumption "too aggressive"?
The exponential growth model is a stress-test assumption intended to surface late-stage failure modes. Slower compounding delays the crossover point but does not change the relative ranking of strategies.
Why "change delivery capacity" and not "value" or "features"?
Value depends on what you build and whether the market ultimately cares. Features conflate scope with impact. This simulator focuses on something more fundamental: how effectively the system can absorb and implement change.
Change delivery capacity reflects the system’s structural freedom to evolve. Teams with high capacity can respond to feedback, pivot when assumptions are wrong, and deliver what matters. Teams with low capacity are constrained by their system, regardless of how good their ideas are.
How should you use this simulator?
To compare strategies, not to forecast outcomes. The absolute numbers matter less than the difference between trajectories under different assumptions.
I build tools like this to make long-term tradeoffs visible before they become constraints. My work focuses on how software systems evolve over time:how structure, incentives, and local decisions compound into outcomes teams later experience as technical debt, delivery friction, or stalled change.
I'm particularly interested in how small choices accumulate, and how changing the system, not just the code, changes what's possible.
More on my approach