Technical debt, architecture erosion and drift

What Ward Cunningham actually meant

The term technical debt comes from Ward Cunningham's experience report on the WyCash portfolio management system, presented at the OOPSLA conference in 1992. He wrote that shipping first-time code is like going into debt: a little debt speeds development, as long as it is paid back promptly with a rewrite, and the danger comes when it is not repaid: Every minute spent on not-quite-right code counts as interest on that debt. Whole engineering organisations, he warned, can be brought to a standstill under the debt load.

The metaphor is often misread as permission to write sloppy code. Cunningham later explained (in a short 2009 video) that this was never his meaning. His point was about understanding. A team ships code that reflects its current, partial understanding of a problem, because that is the fastest way to learn from real use. As understanding improves, the code no longer matches what the team now knows, and every change has to work around the mismatch. Repaying the debt means refactoring the code so that it reflects what has been learnt. That only works if the code was written cleanly enough to be refactored in the first place. On this reading, debt is a by-product of learning, not of carelessness.

Since then, usage has broadened. Today "technical debt" covers any internal-quality shortfall that makes future change slower or riskier, whether it arose from learning, deliberate shortcuts, ignorance or plain neglect. The broader meaning is useful as long as you remember that the different kinds call for different responses.

Principal and interest

The financial vocabulary is what makes the metaphor powerful in conversations with non-engineers. The principal is the effort needed to fix the problem: to restructure the module, separate the database, remove the cycle. The interest is the extra effort paid on every piece of work that touches the problem while it remains. Martin Fowler's illustration: if a feature would take four days in clean code but takes six because of cruft, the two extra days are interest.

Three consequences follow. First, debt that is never touched costs nothing: a messy module that nobody changes accrues no interest, so repaying it may be wasted effort. Second, interest compounds: workarounds become foundations for more workarounds, new developers copy the patterns they see, and the cost of the eventual repair rises. Third, repayment is an investment decision: it is worth paying the principal when the interest you will save over a sensible horizon exceeds it. That turns an emotional argument ("the code is a mess") into an economic one ("this module costs us eleven days a quarter").

Fowler's technical debt quadrant

Not all debt is equal. In 2009 Martin Fowler proposed classifying debt along two axes: whether it was taken on deliberately or inadvertently, and whether the decision was prudent or reckless. The four combinations call for different responses.

Prudent and deliberate: the team knows the better design, judges that shipping now is worth the cost, and plans to repay. This is Cunningham's original sense, and it can be good business: a start-up proving demand before investing in scale. Reckless and deliberate: the team knows better but skips design because it believes it has no time, usually slowing itself down within weeks. Reckless and inadvertent: the team does not know enough to see that it is creating debt; the cure is skills, review and mentoring rather than refactoring alone. Prudent and inadvertent: a skilled team does good work and only later understands how it should have been structured. Fowler argues this is unavoidable for any team that learns, which is why continuous refactoring is part of normal work rather than a sign of failure.

Architectural debt versus code debt

Debt exists at every level, but its cost profile changes with scale. Code debt lives inside a module: duplicated logic, a function that does five things, missing tests, poor names. It is real, but it is local; one developer can usually repay it in hours or days, often while working on a nearby feature. Architectural debt lives in the structure: services that share a database so neither can change its schema alone, a domain split along the wrong lines so every feature touches four teams, a synchronous call chain that makes one slow service take down the checkout, a framework welded into every layer. Repaying it touches many modules, often many teams, and sometimes data.

Research supports the intuition that structural debt is the expensive kind. A 2015 survey of 1,831 engineers and architects by Neil Ernst and colleagues at the Software Engineering Institute found that architectural decisions were the most important source of technical debt reported, ahead of code-level issues. Tools that flag code smells are good at finding code debt and poor at finding architectural debt, because the problem is in relationships between parts rather than in any one file.

Architectural debt matters for the same reason architecture matters at all: as Why architecture matters showed, structural decisions are the ones with the highest cost of change.

Erosion and drift

Architecture debt often accumulates not through one bad decision but through thousands of small changes. Dewayne Perry and Alexander Wolf, in their 1992 paper "Foundations for the Study of Software Architecture", named two ways this happens. Architecture erosion is caused by violations of the architecture: a controller that queries the database directly, bypassing the service layer; a module that reaches into another's internal tables. Each violation makes the system more brittle, like removing a load-bearing wall. Architecture drift is caused by insensitivity to the architecture: changes that break no explicit rule but ignore the intended concepts, so the system gradually loses coherence and clarity of form. Drift is less immediately dangerous than erosion, but it obscures the architecture, which in turn makes violations easier.

Later researchers often use "erosion" for the broader gap between the intended architecture (what the documents and the architect's head say) and the implemented architecture (what the code actually does). Whatever the terms, the causes are familiar:

Deadline pressure that rewards the shortest path over the right path. Knowledge loss when the people who understood the design leave and new staff copy whatever they find. Invisible architecture: rules that live only in a wiki nobody reads, with nothing in the build to enforce them. Changed requirements, which leave a once-good structure fitting the problem badly. Organisational change: by Conway's law, a reorganisation creates pressure for the system to reshape itself along new team lines. Ageing technology: frameworks and platforms that fall out of support turn into debt without anyone touching the code.

Detecting debt

Debt you cannot see cannot be managed, and gut feeling is unreliable: developers tend to complain loudest about the code they touch most, which is useful, but they rarely know how much each problem costs. Several techniques make debt visible.

Hotspots. Adam Tornhill's Your Code as a Crime Scene (2015; second edition 2024) applies forensic ideas to version-control history. A hotspot is code that is both complex and changed often. Complexity alone is not enough: a complex file nobody touches costs no interest. Change frequency alone is not enough: a simple configuration file can change daily without harm. Where the two coincide, debt is being paid on every commit, and that is where repayment pays off first. In most codebases a small fraction of files accounts for most of the change activity.

Change coupling. Files or services that keep changing in the same commits are coupled, whether or not the code shows a dependency. If every change to the pricing service is accompanied by a change to the invoicing service, they are one thing pretending to be two. Change coupling across team or service boundaries is a strong sign of architectural debt.

Dependency cycles and rule violations. Static analysis can draw the real dependency graph and compare it with the intended one. Cycles (A uses B, B uses C, C uses A) mean none of the three can be understood, tested or released alone. Architecture rules ("the domain layer must not depend on the web layer") can be checked automatically on every build; these are fitness functions, covered in Chapter 11.

Delivery trends. Rising lead time for changes, more defects escaping per release, longer onboarding, more coordination meetings per feature and growing reluctance to touch certain areas are lagging indicators of accumulated interest. The DORA delivery metrics (such as change lead time and change fail rate) give a consistent way to track some of these over time.

Managing debt

No healthy codebase has zero debt, and trying to reach zero is itself a waste. The goal is to keep debt visible, deliberate and affordable. Teams that do this well combine several practices.

A debt register. Record significant debt items where the team plans its work: what the problem is, where it is, how it arose, the estimated principal, the estimated interest (with evidence such as hotspot data or recent tickets), and the trigger for repaying it. A register turns vague complaints into a list that can be prioritised alongside features.

A fixed share of capacity. Many teams reserve a steady proportion of each iteration, commonly somewhere between 10 and 20 per cent, for debt repayment and other improvement work. There is no evidence for a magic number; what matters is that the share is protected and does not disappear whenever a deadline looms.

Refactoring alongside features. The cheapest time to repay debt is when you are already working in the area, because you have the context loaded and the tests running. Fowler calls this opportunistic refactoring. Its everyday form is the boy scout rule, popularised by Robert C. Martin: leave the code a little cleaner than you found it. Because hotspots are by definition where features land, this naturally concentrates effort where interest is highest.

Planned structural repayment. Architectural debt rarely yields to small steps alone. It needs an explicit, funded piece of work with a goal, a plan for migrating in increments, and the support of stakeholders. Techniques such as the strangler fig pattern (Chapter 11, Modernising legacy systems) let a team replace a structure piece by piece without a big-bang rewrite.

Prevention. Automated architecture checks in the build, code review that looks at structure as well as style, and up-to-date decision records slow erosion and drift at source.

Explaining debt to non-technical stakeholders

Sponsors and product owners do not need to hear about cyclic dependencies; they need to understand the effect on what they care about: speed, cost, risk and customer experience. The financial metaphor is a gift here, provided you use it with numbers.

Talk in time and money: "Every change to checkout costs us about three extra developer-days because of how payment and orders are tangled together." Talk in risk: "Two of our last four incidents started in this module." Talk in options: "Until we separate these, we cannot offer the new payment methods sales has asked for." And present repayment as an investment with a payback period, not as a plea for engineering time. Avoid two traps: presenting debt as a moral failing of the people who came before (it is usually prudent or inadvertent), and asking for an open-ended "refactoring sprint" with no measurable outcome.