§ 92
Technical Debt
Code shipped before the team fully understands the problem charges extra on later changes to that code until someone rewrites it.
Keep in mind
Record shortcuts as loans, and repay them where you change code most
What to do
Treat code written before the team fully understood the problem as a loan: write down where it is and what repaying it would take, and schedule the rewrite while the code is still fresh in someone's head. Repay first where the team changes code most often, not where the code merely looks worst. Do not let debt pile up unrecorded.
Why it happens
The first version of a program records what the team understood when it wrote it, and that understanding keeps improving after the code stops changing. Every later change has to work around the gap between the two, and the extra effort recurs on each change the way interest recurs on a loan. The cost is spread thin and lands on whoever touches the code next, so no single change makes repaying it look worthwhile, and the balance grows until the whole team slows down. Cunningham did not object to the shortcut itself; his warning was about debt that is not paid back with a rewrite while it is still small.
When it stops applying
Premature Repayment: paying down debt early spends time on code whose design may still change or that may be deleted before anyone touches it again, so cleaning up ahead of the next change can cost more than the interest it saves.
Source
Ward Cunningham, The WyCash Portfolio Management System (OOPSLA '92 Experience Report, 1992) — "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite." and "Every minute spent on not-quite-right code counts as interest on that debt." The prudent/reckless distinction is from Martin Fowler, Technical Debt Quadrant (martinfowler.com, 2009).
Read the sourceCite this
Hammurabi, § 92, “Technical Debt.” https://kanywst.github.io/hammurabi/laws/technical-debt/
BibTeX
@misc{hammurabi-technical-debt,
title = {Technical Debt},
author = {{Hammurabi contributors}},
note = {Hammurabi, § 92},
url = {https://kanywst.github.io/hammurabi/laws/technical-debt/}
}Read in a column
- Living with old code Next in the column: Boy Scout Rule
Related laws
- 93Lehman's Laws of Software EvolutionA program in real use must keep changing or grow less useful, and each change makes it more complex unless work is spent to simplify it.
- 29Boy Scout RuleCode decays because cleanup tends to be deferred to a refactor that rarely happens.
- 89Fixed Time, Variable ScopeWhen scope is fixed and time is not, the date slips and the scope stays; fixing the time instead forces a choice about what matters.