The Harris Matrix of Technical Debt

What a 1973 archaeologist with one pencil figured out about your tech-debt backlog — and why teams keep trying to solve a graph problem by sorting a list.

One evening in February 1973, in Winchester, England, an archaeologist named Edward Cecil Harris sat down with the field notes of a 1960s excavation he could not make sense of. The site had generated the kind of record that was normal for its time: one-dimensional physical sections, profiles drawn on graph paper — depth of soil on the page, time flowing downward by assumption. Read the drawings carefully and the site still refused to resolve. Which wall was built before which floor? Which pit cut through which midden? He had the drawings. He could not get from the drawings to the story.

By morning he had invented the Harris Matrix.

What he did that evening was not fieldwork, and it was not a better drawing. It was a refusal — the refusal to let the answer live inside the two-dimensional profile at all. He threw away the section and drew, instead, a graph: one node per stratigraphic unit, one edge for every "this sits above that" contact, and only for the immediate contacts. Any wider ordering would emerge on its own. What looked like a drawing problem had always been a graph problem. No one before him had made the move.

That is the kind of move I want for software debt.

What Harris actually built

By 1979 the method had a book — Principles of Archaeological Stratigraphy — and by the mid-1980s it had become the UK's recording standard through the Museum of London's single-context planning method. The machinery is embarrassingly simple. Harris laid out four laws:

1. 
   Superposition — upper layers are younger, lower layers older, unless disturbed.


2. 
   Original horizontality — deposits settle flat; tilt means something happened later.


3. 
   Original continuity — deposits end at natural edges or at later cuts.


4. 
   Stratigraphic succession — a unit's position is fully defined by contact with whatever is immediately above and immediately below it. All other superpositional relationships, Harris argued, are redundant.

Law four is the one that matters. It is the same insight that makes Hasse diagrams work in order theory: if you have ordered pairs A<B and B<C, you do not need to draw A<C. It falls out of the graph for free. An excavation that once looked hopeless — thousands of context units in a city-centre site — becomes tractable because you only record neighbouring relationships, and the full ordering computes itself.

There is a second Harris insight that lands as harder for software readers to hear. The principle at the heart of his recording method is that surfaces, not deposits, are the load-bearing unit — the moment one layer meets another is what tells you the story. Soil persists; you can put it in a bag and bag-number it. An interface is transient. It exists only until the trowel goes through it. If nobody records what it looked like before it was destroyed, that piece of the story is gone.

Hold that thought. It will come back.

What software calls debt

Software's version of this problem is fifty years younger and about forty-four years behind on method.

The phrase technical debt was coined by Ward Cunningham in 1992, in his OOPSLA experience report on the WyCash portfolio system, after reading Lakoff and Johnson's Metaphors We Live By. The argument was financial: 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. Interest accrues in the form of compounding friction. Miss enough payments and eventually all your effort goes to servicing the debt and none to building.

Martin Fowler upgraded the frame in 2009 with the Technical Debt Quadrant — a 2×2 of (deliberate vs. inadvertent) × (prudent vs. reckless). It was a lovely diagnostic. It said: this category of debt is the kind a competent team takes on knowingly; that category is the kind you accidentally ship because you did not know any better. Prudent deliberate debt is often wise. Reckless inadvertent debt is how companies die.

What Fowler's quadrant does not do — what no mainstream debt framework does — is tell you the order in which to pay the debt down. The quadrant describes each item in isolation. Two items of prudent-deliberate debt look identical on the diagram even when one is blocking the other. You still need to know: if I take the afternoon to rewrite the legacy auth middleware, will that unblock the permissions refactor I've been avoiding for two release cycles? Does the permissions refactor in turn unblock the multi-tenant work the sales team keeps asking about?

Every engineering team I have ever watched has answered that question by scrolling through a flat list in Jira. A priority score is a number. A number is one-dimensional. Dependencies between debt items are a graph. Teams keep trying to solve a graph problem by sorting a list.

The tooling that claims to help mostly does not. Debtmap, an open-source analyzer that has been gaining attention since 2024, calls itself a "tiered prioritization" tool and surfaces architectural issues above testing gaps — a real improvement over ranked severity, but still a ranking. CodeScene does behavioural code analysis, weighting hotspots by developer activity from git history. NDepend draws handsome dependency graphs of code and stops short of linking those graphs to the debt list itself. None of them render debt as what it actually is: a directed acyclic graph where an edge from A to B means "you have to deal with A before B becomes tractable."

The gap is the shape of the data structure, and no amount of ranking fixes it.

The mapping, row by row

Here is what the correspondence looks like when you put archaeology and software side by side rather than inside each other:

Each row does specific work. Read down the column and an engineering team has, for free, the vocabulary they have been reaching for.

Take a shape of the kind most teams have. Imagine the team still owns a handwritten auth middleware written in a hurry when the company had six employees. Above it, grafted on over four years, is a permissions system that depends on quirks of the middleware ("users are always in exactly one org, because that's how the old middleware parsed the JWT"). Above that sits the multi-tenant feature sales keeps asking about — which cannot ship because permissions are single-tenant-shaped, which in turn are the shape they are because of the auth middleware below. Three debt items. Ranked by business value, multi-tenant is on top. Ranked by Fowler's quadrant, all three might be "prudent deliberate" and tied. Drawn as a Harris Matrix, the ordering is unambiguous: the auth middleware is the lowest stratum, and nothing above it is fully tractable until it is handled.

Starting at the top layer — the "highest-value" one by priority score — is the archaeological equivalent of trenching downward through three centuries of wall to get to a coin you can see glinting through a crack. You will find the coin. You will also destroy the record of everything above it.

Prior art, and what's left

I should say, because it would be dishonest not to: the observation that software stratifies like an archaeological site is not original to this essay. In 2018, Andrew Reinhard of the Centre for Digital Heritage at the University of York published "," martinfowler.com, 14 October 2009. Museum of London single-context planning, developed in the late 1970s and exported as a UK standard from the mid-1980s. Debtmap ( · See a signed dependency record · pip install agent-rating-protocol