How high is the extra effort so far after 3 months, and what does the repayment cost?

18 hours of extra effort so far; the repayment costs 30 hours one-time (illustrative).

The shipping module reads order tables directly and costs 6 hours per month. When is the repayment via the order contract economical?

From month 5: there the extra effort so far equals the repayment of 30 hours. After that it increasingly pays off.

The team postpones the repayment. What speaks for it, what speaks against it, and what do you recommend?

Advantage: no rework cost now, capacity for new work. Disadvantage: the interest keeps growing by 6 hours per month. Recommendation: plan the repayment with a review date, at the latest by month 5.

ConceptChapter III · Evolution · Building block 3 of 7

Technical debt

Technical debts shift expense or risk into later work. Their “interest” is reflected, for example, in recurring additional effort, manual steps or a higher probability of error.

By Michael Meierhoff · Meierhoff Systems

InterestRecurring extra effort of the shortcut.
EradicationOne-time rework ends the interest.
Break-evenFrom here, the repayment pays off.

Context

Why this is important

Not every unpleasant place deserves effort. Without observable consequences decides gut feeling, and really expensive debts remain. The evaluation after recurring work makes priorities justifiable.

This building block evaluates follow-up costs and repayment. Architecture erosion describes structural deviations; trade-off analysis compares targeted alternatives.

At a glance · From shortcut to repayment

A shortcut creates debt at one point; its interest accrues as ongoing extra cost until a repayment removes it.

Shop example · Playing through stages

Interest of the shortcut over months

The shipping module reads order tables directly. Any change to the status field requires manual tuning and causes recurring error checks.

This is how you read the picture

Interest Metric 'extra effort so far' grows with 'months since the shortcut'.
Eradication Metric 'repayment one-time' and the switch 'debt repaid (one-time rework)'.
Break-even At 5 months, 'extra effort so far' and 'repayment one-time' both show 30 h.

Months since the shortcut: 3 months

18 hExtra effort so far
30 hRepayment one-time

The interest adds up: after three months, 18 hours of extra effort have already accrued.

Values illustrative

Move the months and switch on the repayment to compare interest and repayment.

Benefits & limitations

Helps if:

Recurring changes show additional effort or consequences of errors at a specific technical point.
Time-limited deviations benefit from visible follow-up work and a defined reassessment date.

Boundaries

Without observed frequency of change and additional effort, the priority remains gut feeling; numbers arise from real work, not from estimation in advance.
A comprehensive rebuild increases transition risk; targeted repayment along the affected change path is often cheaper, for example through Strangler.
Naming debt does not remove it; checks such as those in Architecture erosion prevent new violations.

In practice

Identify the question and consequences. Describe the technical location, recurring extra effort or concrete risk, and the affected change. Separate observed consequences from assumptions. This produces an assessable debt record.
Weigh timing and impact. Check when the area will change again and how deferral affects goals. Compare benefits, costs and alternatives. This prioritises repayment by expected burden rather than visibility alone.
Repay selectively and measure again. Plan a bounded improvement with clear impact measurement and review the next comparable change. Update the record using actual costs. This shows whether the measure reduced interest.

Read the detailed explanation

Technical debt shifts effort or risk over time. “Interest” describes recurring consequences such as slower changes, more manual steps or a greater likelihood of failure; “repayment” means targeted improvement. A deviation matters when its consequences affect expected future work. This assessment complements observation of Architecture erosion and a sound Trade-off analysis.

Debt can be deliberate, enabling learning or timely delivery, or emerge unintentionally through change. A useful record identifies the location, consequence, affected work and review date. Priority depends on likelihood and impact; aesthetic preference alone does not justify repayment. Linking targeted repayment to related work may create less risk than a major rebuild. Measurements from recurring changes help confirm or reassess the assumed burden.

Check your understanding

Test yourself in three stages

ReadingCheck in the picture
How high is the extra effort so far after 3 months, and what does the repayment cost?
View the solution with justification
18 hours of extra effort so far; the repayment costs 30 hours one-time (illustrative).
ApplyingTransferred to a new situation
The shipping module reads order tables directly and costs 6 hours per month. When is the repayment via the order contract economical?
View the solution with justification
From month 5: there the extra effort so far equals the repayment of 30 hours. After that it increasingly pays off.
EvaluateWeighing an alternative
The team postpones the repayment. What speaks for it, what speaks against it, and what do you recommend?
View the solution with justification
Advantage: no rework cost now, capacity for new work. Disadvantage: the interest keeps growing by 6 hours per month. Recommendation: plan the repayment with a review date, at the latest by month 5.

Explore further

These optional deepenings complement the learning goal of this page.

Software Analytics

Software Analytics uses code and development data to investigate concrete questions about system behaviour and change work. The process moves from a question, suitable software data and a testable hypothesis to investigation and a justified action. Change frequency, complexity and co-changes can indicate hotspots or suspected coupling. These indicators establish neither causation nor individual performance.

In the shop, the team asks why order changes often touch the catalogue and payment modules. It compares change history and complexity, examines representative commits with their business context, then chooses targeted debt repayment or further observation. The action follows verified consequences.

For testingConnect the question, data and findings. Investigate why changes to the shop’s order module touch several areas. Compare change frequency and complexity, review shared commits with their business context, then formulate a hypothesis with suitable debt repayment or further measurement. Treat metrics as indicators, not evidence of causation or performance.

References

Continue on the learning path

Next in Evolution & assessment: Architecture erosion.

7 Building blocks

Continue withArchitecture erosion