Ward Cunningham: Ship Early, But Repay Technical Debt
Ward Cunningham, who coined "technical debt," said shipping early to learn is like a loan: valuable only if you repay fast. Teams that never refactor see progress drop to zero as all effort goes to interest. Use debt to buy learning time, then refactor.
WHY IT MATTERS: Most teams treat technical debt as a moral failing or hygiene issue, which leads to either reckless accumulation or paralysis by upfront design. Ward Cunningham's original definition reframes it as a deliberate financial instrument. When you borrow money, you can act sooner, but you must pay interest until the principal is gone. In software, that interest is the friction of working with code that does not reflect your current understanding. Misspelled objects, hidden coupling, and confusing flows are all interest payments. If you never repay the principal through refactoring, the interest eventually consumes 100 percent of your capacity and progress stops completely. This is not a metaphorical risk; it is a mathematical certainty for long-lived codebases that grow without reorganization.
WHAT CHANGED: Cunningham clarified that technical debt is not about cutting corners or laziness. It is the gap between what you now know about the problem and what the code currently expresses. In complex domains, trying to discover every requirement, data structure, and architectural boundary before writing code is economically wasteful. Instead, you ship early to gain real experience, accepting that the initial code will need rewriting as understanding improves. The critical condition is that each new insight must be paid back immediately by reorganizing the program to match your current mental model. The debt is only a tool if repayment is built into the workflow, not postponed indefinitely.
WHAT TO WATCH: Audit your backlog for debt that has no repayment plan or owner. If tickets are tagged as technical debt but never scheduled in the next two sprints, you are not borrowing to learn; you are defaulting. Measure whether recent refactors actually reduced the time needed to add similar features. If cycle time is flat or rising, your interest is still compounding. Also watch for teams using debt as an excuse for poor design in simple, well-understood domains. Cunningham noted that non-complex work should not require loans because the learning is already available. Reserve the debt metaphor for genuine exploration.
Read the original → scrum.org
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.