Technical debt and the cost of the next change
Technical debt is a design or implementation problem that can add effort or risk to relevant future work. A shortcut may create it, but not every edit pays a cost and routine maintenance does not automatically reduce it. Deliberate decisions compare benefits, costs and risks and record a cleanup or review plan.
What a learner can do afterwards
- Identify a shortcut and estimate its added change effort or cleanup cost
- Compare benefits, costs and risks when deciding whether to accept debt, with a cleanup or review plan
- Distinguish evidence of added future cost or risk from age or style alone
1 · Read
Technical debt can add effort or risk to relevant future work. The loan terms are an analogy: principal means work needed to reduce the underlying problem, and interest means added effort from working around it. Software debt need not follow a loan schedule, and its costs need not increase over time.
Hard-coded delivery zones may need code edits where a table allows a data update. Both need checking; overhead is only the additional work compared with the alternative. Adding another hard-coded zone can leave duplication and the same design in place. Moving zones into a suitable table is separate cleanup work, not another zone update. Cleanup reduces the cause of overhead or risk; check what changed before calling routine maintenance a repayment.
A deliberate plan records the shortcut, expected benefit, added effort and risk, an owner, and a cleanup date or review trigger. Writing the plan does not mean repayment is complete. At review, the team may clean up, defer with reasons, accept the remaining cost or retire the affected code.
Compare like-for-like effort. In this example an update takes 45 minutes now and 15 minutes with the alternative. The added effort is 45 minus 15, or 30 minutes per update. Both totals include their required checks; do not label all current testing time as debt overhead.
Debt may affect only particular changes or create a plausible risk that has not occurred yet. Overhead can stay steady, grow or fall with the workload. Without a cleanup date, it may recur, but automatic compounding and permanent nonpayment do not follow.
Consider the remaining workload. If code will retire before the costly kind of change occurs, cleanup may cost more than it saves. Check ongoing risks and how certain the retirement plan is before choosing that path. Review the decision if plans change; age alone is not a reason either to rewrite or to keep code.
A deadline is only part of a debt decision. Compare the expected benefit of shipping now with implementation effort, future overhead, cleanup cost and relevant failure risks. A dated ticket cannot make an unsafe or uneconomic shortcut worthwhile. Accept a shortcut only when the stated assessment supports it.
Estimate cleanup scope before deciding. Add the effort for the design change, necessary regression checks and other required tasks; do not count only the edit itself. Age or disliked naming alone does not establish debt. Identify the added future effort or a plausible risk caused by the design.
For a simplified effort comparison, assume cleanup removes a constant positive overhead per future change. Divide cleanup minutes by minutes saved per change, then round up to a whole change. This gives the number needed for saved effort to cover cleanup. The comparison depends on the stated assumptions and excludes unpriced risks.
For different kinds of planned work, multiply each kind's change count by its estimated saving per change. Add those savings, then subtract cleanup effort to find net minutes saved. A negative result means extra effort over that horizon. Estimates are not guarantees; assess risks separately.
An observed regression can support a specific risk claim. If duplicated rules diverge and a change breaks related features, record that mismatch and investigate the cause. One observation does not prove every future edit will fail or take longer. Keep evidence, estimates and universal claims distinct.
Identify added effort or risk. Compare alternatives and record a review plan. Routine work does not automatically reduce debt, and estimates are not guarantees.
Original software-debt lesson, questions and flashcards written for this learning dataset.
Original questions and software readings written for this learning dataset.
2 · Watch
En anglaisTake it off screen
Where it sits
14 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.