Guides  /  Rollout and delivery

What happens to technical debt over the life of the system?

Answer

Technical debt accumulates when the account of what a system should do and the system itself move apart. Each change that nothing reconciles with the specification adds to the distance.

Akka Specify verifies every change against the specification, so the code never drifts from it. Technical and knowledge debt stop accumulating over the life of the system.

The mechanism

Rework consumes 20 to 40% of engineering capacity.

Engineering capacity lost to rework caused by earlier architectural choices runs at 20 to 40%. The choice that caused it was reasonable when it was made, and the cost arrives once enough of the system depends on it.

Knowledge debt runs alongside it. The reason a component works the way it does lives with the people who built it, and it leaves when they do. A team maintaining a system it did not design pays for that gap on every change.

WITHOUT THE SPECIFICATION a change it mergesthe reason is losta team works around it rework it is verifiedthe reason is recordeda team reads itthe next change fits WITH THE SPECIFICATION
Where debt enters

Each unreconciled change makes the written account less accurate.

An undocumented changeBehaviour changes and the specification does not, so the document describes a system that no longer exists.
A verbal exceptionA reviewer allows a departure in a meeting, and the exception leaves no trace once that reviewer moves on.
A shortcut under time pressureA workaround ships and the reason for it is never written down, so a later team reads it as a design choice.
An early dependencyOne architectural choice sets what every later change works around. Switching cost off a first-choice runtime grows non-linearly with the size of the deployed base.
What enforcement changes

The specification stays accurate because a change cannot leave it.

Every change is verified against the specification before it merges, so the specification describes the running system at every point in its life. A team that joins later reads the requirement instead of reconstructing it from code.

An exception is written into the specification, where it carries an author, a scope and a review. Debt prevention becomes a guarantee of the delivery model.

Questions

Related questions.

What about the debt a system already carries?

A specification written against what the system is meant to do makes the gap visible on the first check. Every requirement the running code does not meet is reported, and that list is the backlog.

Does this cover knowledge debt as well as code?

The specification carries the goals, the risk envelope, the knowledge sources and the operational envelope. The reasons behind the system are in the artifact every change is checked against.

What happens when the platform version changes?

The specification describes the system in its own terms, so agents stay portable across deployments and Akka versions. An upgrade is verified against the same specification.

Who owns the specification after delivery?

The customer maintains the specifications. Extending the system means editing the artifact the check reads.

How does this show up in cost?

Rework runs at 20 to 40% of engineering capacity, and GenAI projects that scale past pilot run 2x to 3x over cost. The two figures measure decisions made early and paid for later.

On Akka. Specification-checked change and debt prevention are part of Akka Specify. Figures. Rework, cost-overrun and switching-cost estimates come from the BCG, Deloitte and McKinsey studies cited on the efficiency page.