How expert witnesses assess technical debt as evidence: the codebase and its history, industry benchmarks, the supplier's standard of care, and reporting under CPR Part 35.
Technical debt is a phrase software teams use constantly and rarely define. It covers the shortcuts, the deferred work, and the structural compromises that accumulate in a codebase as it is built and changed under pressure. To a working developer it is an unremarkable fact of the job. Increasingly, it is also something I am instructed to assess in a dispute.
It reaches litigation by several routes. A buyer completes an acquisition and finds the codebase in materially worse condition than the warranties implied. A fixed-price project is delivered to specification but leaves behind a system the client’s own team cannot maintain. A supplier hands over a working application that then resists every attempt to extend it. In each case the functioning software may be beside the point; the dispute is about the state of the thing underneath it.
The forensic difficulty is that the supplier has a ready answer, and it is largely a true one. Every codebase carries debt. No real system is built without compromise, and “this is normal” is a comfortable position to defend. A solicitor who frames the complaint as “there was technical debt” has framed a complaint that goes nowhere, because the honest answer is that yes, there was, as there is everywhere.
The question a dispute actually turns on is narrower. It is whether the kind, the amount, and the management of the debt fell below what a reasonably competent supplier would have produced under comparable constraints. This guide documents the methodology I use to answer that question.
What Technical Debt Is, in Litigation Terms
The phrase comes from Ward Cunningham, who in 1992 described shipping imperfect code as a way of borrowing against future development: you go faster now and pay it back later, with interest, in the extra effort every subsequent change demands. It is a good metaphor and it has carried the idea a long way.
It also has a limit that matters in court. A credit card states its interest rate; you know what the borrowing costs before you take it on. Technical debt does not. Its interest stays invisible until you try to ship the next change and find the cost everywhere at once, spread across files nobody flagged and decisions nobody recorded. That invisibility is the whole forensic problem. The expert’s task is to make a cost that was never written down measurable after the fact.
The distinction that decides most of the analysis is between two kinds of debt. There is the deliberate trade-off: taken knowingly, recorded at the time, with a plan to recover it. And there is accumulated drift: debt that compounds quietly because no one named it, priced it, or scheduled its repair. The first is ordinary engineering. The second is where disputes live.
Several public frameworks give the assessment something firmer than impression to stand on. The DORA metrics, published in Google’s State of DevOps research, benchmark delivery performance, and sit within the wider library of industry standards a court can test. The SQALE method quantifies the effort required to remediate debt. CISQ, the Consortium for Information & Software Quality, publishes measurable quality criteria derived from source code. And the academic literature on self-admitted technical debt studies the debt developers confess in their own code comments. None of these answers the legal question on its own. That question is not whether debt exists, but whether its kind, amount, and management match what a reasonably competent supplier would have produced under comparable constraints.
Reading the Codebase and Its History
The first body of evidence is the codebase itself, examined as a static artefact. A number of its properties can be observed directly and, where it helps, measured: duplicated logic, methods whose cyclomatic complexity puts them beyond safe modification, dependencies left years out of date, areas the automated tests never reach. None of these is damning on its own. Together they describe the condition of the code at the moment it became the subject of a dispute.
The condition at one moment, though, is the weaker half of the picture. The stronger half is how the code arrived there, and for that I read the version control history as a forensic timeline, much as I do when examining source code in IP disputes. A repository records when refactoring was happening and when it stopped, when change slowed because every edit had become expensive, where bursts of intense feature delivery were followed by no corresponding investment in quality. The code tells you what state the system is in. The history tells you how it got there, and when, and under what pressure.
Within that history, one pattern deserves separate attention. Developers annotate their own shortcuts: a TODO to come back to something, a FIXME over a section known to be fragile, the occasional candid HACK. This is self-admitted technical debt, and it is unusual as evidence because the supplier wrote it. Where these markers accumulate over years and the history shows no later commit returning to clear them, they are the supplier’s own contemporaneous record of debt it knew it was taking and chose not to repay.
A handful of TODO comments is the ordinary texture of working software; thousands of them, with commit dates spanning years and no answering cleanup, is a different finding altogether.
The history is also where architectural decisions are visible, or conspicuously absent. Where a significant structural change was proposed, attempted, completed, or abandoned, the record usually shows it. So does the case where the system plainly needed such a change and none was ever begun. That second pattern, the rewrite that should have happened and did not, is often more telling than anything in the code as it stands today.
Industry Benchmarks and Their Limits
The value of an external benchmark is that it lets an expert say something a court can test, rather than something resting on the expert’s taste. The most widely recognised is the set of DORA metrics: deployment frequency, lead time for changes, change failure rate, and time to restore service. They were not designed for litigation, but they describe delivery performance in the terms comparable teams are measured against every year. A team sitting in the bottom quartile on several of them at once is operating below what its peers routinely achieve, and that is a defensible thing to put in a report.
Static analysis tools provide a second kind of instrument. Products such as SonarQube, CodeClimate, and CodeScene scan a codebase and return an estimate of the effort needed to remediate what they find, often expressed in days or money. I name them as instruments, not recommendations; each carries its own model and its own blind spots. The number such a tool produces is the input to expert judgement, never the conclusion. A remediation estimate tells you what the tool measured, not what it means.
The SQALE method offers one way of turning those measurements into a single figure, the technical debt ratio, which expresses remediation cost against the cost of building the system afresh. It is defined, it is recognised, and it is not universally agreed. CISQ supplies another reference point: measurable quality criteria derived directly from source code. Both are useful precisely because they are public and repeatable. Neither settles the question by itself.
That is the honest limit of the whole apparatus, and saying so plainly strengthens an expert’s position rather than weakening it. No single number resolves whether a supplier fell short. The tools and frameworks produce measurements; what matters in law is whether those measurements show the supplier operating outside the range of reasonable practice. The benchmark is evidence the court can engage with. The judgement about what it indicates remains the expert’s to make and to defend.
It also has to be calibrated. The standard reasonably expected of a ten-year-old payments platform carrying real money is not the standard expected of a two-year-old product still finding its market. Project age, team size, the constraints written into the contract, the domain and its risks: all of these move the line before any conclusion is drawn. An expert who applies a benchmark without calibrating it to the specific system invites exactly the cross-examination that calibration would have answered.
When Debt Reaches the Standard of Breach
Most debt never reaches a dispute, and most that does is defensible. The patterns worth an expert’s attention are the ones where the debt has stopped being a private engineering cost and started defeating something the client was entitled to. A few recur.
The first is architectural debt that renders a contracted requirement unbuildable. Early structural choices, reasonable enough when made, harden into a shape the system cannot grow out of, and a requirement that should have been a fortnight’s work becomes “we would have to rewrite half the system to do that.” In disclosure this shows up as a feature repeatedly quoted, deferred, and re-estimated upward. The supplier’s defence is that the requirement was a change of scope. What cuts through is showing that the requirement sat within the original specification, and that it is the supplier’s own architecture, not the client’s ambition, that put it out of reach.
The second is knowledge concentrated to the point of system risk. A codebase can reach a state where only its original authors can safely change it: no documentation, no shared conventions, structure that lives in one or two people’s heads. This matters because the client was buying a maintainable asset, not a standing dependency on individuals who are free to leave. The supplier will say the system works, and it may. What cuts through is the handover test: once the original people had gone, could anyone else operate and extend what remained? Where the answer is no, the asset delivered was not the asset promised.
The third is debt compounded past the point of economic repair. Some systems reach a condition where further development costs more than it returns and no incremental fix restores them; the only honest route forward is substantial replacement, a finding that often sits inside a wider failed software project assessment. This is the point at which engineers talk about declaring bankruptcy on a codebase. It matters twice over. It is evidence of how far practice fell short, and it reframes the damages, because the loss is then measured against the cost of replacing the system rather than the cost of maintaining it.
What these patterns share is that the harm is demonstrable without asking the court to adjudicate taste. In each, the debt has produced a consequence the client can point to: a requirement that cannot be met, a system no one can maintain, an asset that has to be rebuilt. That is the threshold. Debt becomes evidence of breach at the point where it stops being a quality the engineers dislike and becomes a result the client did not agree to bear.
The Supplier’s Standard of Care
The question the supplier wants the dispute to be about is “how much debt is too much?” It is a good question for the defence, because it has no settled answer. Reasonable engineers disagree about acceptable debt levels the way they have disagreed about agile and waterfall for twenty years, and a dispute that turns on that disagreement turns on something a court cannot cleanly resolve.
The stronger question is not how much debt the supplier created, but how the supplier behaved towards it. Taking on debt is not a breach. Taking it on blindly is. A reasonably competent supplier discharges four duties as debt accrues: it recognises debt as it is being incurred, records the material debt in artefacts that survive, surfaces debt to the client when it bears on scope, cost, or risk, and manages it deliberately instead of letting it compound in silence. The expectation scales with the project’s age and complexity, but the four duties hold throughout. A supplier who met them produced debt within reasonable practice. A supplier who met none of them did not, whatever the raw quantity turns out to be.
This is the same move that decides requirements disputes. There, the argument that survives is not “agile or waterfall” but whether the discipline of specification was adequate to what the case now asks of it. Here, the argument that survives is not the debt ratio but whether the supplier exercised the discipline that taking on debt responsibly requires. DORA and CISQ give a court recognised, measurable reference points to engage with; they are not the only frameworks, but they are defensible ones against which a specific supplier’s conduct can be assessed.
The discipline, where it was exercised, leaves a documentary trail. Its absence is itself the evidence, and it has a recognisable signature: no record of any intent to address debt the supplier knew about, no sign of prioritisation between the debt that mattered and the debt that did not, nothing to show the client was ever told, no decision taken with the risk weighed and owned. Any one of these absences is suggestive. Found together, across a project that ran for years, they describe a supplier that did not manage its debt at all.
That is why the strongest expert position on technical debt is rarely the size of the number. It is the discipline the supplier can be shown to have exercised, or the discipline the record shows was never there.
Writing Findings That Survive Cross-Examination
An expert report on technical debt is written for the court, and under the Ikarian Reefer principles its duty is to the court rather than to the party that instructed it. That duty should be felt most where the temptation is greatest, and in a debt analysis the temptation is to lead with a number. “The technical debt ratio is fourteen per cent” looks authoritative and saves a great deal of explaining. It is also close to useless to a court, and it will not survive cross-examination, because the first question will be what the number means and the second will be why it should be believed.
Present the methodology first and the finding second. Set out the benchmark used, the calibration applied to it, and the specific evidence it was applied to, so the court can follow the reasoning before it reaches the conclusion. Then give the finding, distinguishing what the measurements show from what you infer from them.
Acknowledge the alternative explanations before you dismiss them. Where a level of debt could plausibly be put down to the age of the system, to turnover in the team, or to what is genuinely normal for this class of software, say so, explain why you nonetheless regard it as indicative of a shortfall, and let the court weigh the competing accounts. An expert who has visibly engaged with the other side’s explanation is more credible than one who appears not to have considered it.
Expect to be cross-examined on the instruments as closely as on the conclusions. If a static analysis tool produced a figure, know what it does not capture. If a SQALE ratio was applied, be ready to show the calibration was even-handed. I keep a detailed working log throughout, recording not only what I found but how I looked for it; it never forms part of the report, but it is the best preparation there is for a difficult cross-examination.
The most contested point will always be the quantification. The position that holds is benchmark plus judgement, not benchmark alone, and it is honest about producing a defensible range rather than a single decimal asked to carry more weight than it can.