01What this document is for
You are being asked to fund work on the basis of a number. You should be able to interrogate how that number was produced before you rely on it.
Most technical debt assessments are a framework applied by a person. Change the person and the answer changes, which is why the resulting figure rarely survives contact with a finance function. The method described here is instrumented: the classification step has published reliability statistics, and every judgment that remains is named as a stated assumption rather than buried in expertise.
Nothing here is proprietary in a way that prevents your team from checking it. The measurement tooling is ours; the logic is yours to challenge.
02The chain, end to end
- 01InputsInterface control documents, requirements, design review records, test reports. Change and defect history where it exists. Source access where available.
- 02MeasurementCoupling and debt density mapped across modules and interfaces, producing a structural model rather than a rule-violation count.
- 03Exposure modelDebt-dense regions weighted against your own historical change effort and defect rates to estimate excess rework in days and currency.
- 04SensitivityAssumptions varied across plausible ranges to produce a band, and to identify which assumption the answer actually depends on.
- 05PrioritiesRemediation candidates ranked by return — what to fund, in what order, and what to deliberately leave alone.
Steps 01 and 02 are measurement. Steps 03 to 05 are modeling, and modeling requires assumptions. The distinction is maintained throughout the deliverable so you always know which is which.
03Inputs — and why source code is optional
The assessment reads the artifacts your program already produces. In most complex-systems organizations the architecture is described more completely in interface documentation than in the code, because the code expresses one implementation of a boundary while the ICD expresses the boundary itself.
| Input | What it contributes | Required |
|---|---|---|
| Interface control documents | Boundary definitions, data contracts, coupling edges | Yes |
| Requirements | Allocation across modules; traceability structure | Yes |
| Design review records | Known compromises, deferred decisions, waivers | Strongly preferred |
| Test reports | Verification coverage; where failures concentrate | Strongly preferred |
| Change / defect history | Effort weighting for the exposure model | Preferred |
| Source repository | Sharpens the coupling map; confirms documented boundaries | Optional |
The exposure model is calibrated against your own history. Without it, industry-typical effort multipliers are substituted, the uncertainty band widens materially, and the deliverable says so on the page where the figure appears. A wide honest band is more useful than a narrow invented one.
04Measurement
Each module is characterized by its coupling to every other module — the number and nature of interfaces crossed, the directionality of dependencies, and whether boundaries documented in the ICD are respected in practice. The result is a dependency structure matrix: clusters that should be internally cohesive, and off-diagonal entries where a module reaches across an architectural boundary it was not designed to cross.
Debt is not "code that looks untidy." In this method, architectural debt is coupling that was not intended by the architecture and is not visible in any single artifact. That is why it survives code review — no reviewer sees the whole boundary.
The classifier and what its numbers mean
| Statistic | Value | What it means in plain terms |
|---|---|---|
| Cohen's kappa | 0.84 | Agreement between the classifier and expert human raters, corrected for agreement expected by chance. Above 0.80 is conventionally treated as strong agreement in reliability research. |
| F1 | 0.82 | Balance of precision and recall. The classifier neither over-reports to appear thorough nor under-reports to appear clean. |
| Panel | n = 35 | Practicing engineers, not students, formed the validation panel the classifier was measured against. |
What these figures do mean: the classification step is reproducible. Run it twice, or have a different person run it, and you get materially the same answer. That is the property that lets a number survive scrutiny from someone who would prefer not to fund the work.
What they do not mean: they say nothing about the accuracy of the cost model in section 05. Reliability of classification and validity of an economic model are different claims, and conflating them would be exactly the sleight of hand this document exists to avoid.
05Exposure model
Coupling only matters because it makes change expensive. The model estimates how much of your existing change effort is attributable to coupling rather than to the intrinsic difficulty of the work.
- Establish total engineering effort spent on change within the assessment scope over a trailing period, from your own records.
- Attribute that effort to modules.
- Compare effort per unit of change in high-coupling modules against comparable low-coupling modules in the same organization — this controls for team, domain and process.
- The difference is the coupling multiplier. Excess effort is the portion of high-coupling work above what the same work would cost at the low-coupling baseline.
- Convert to currency at your fully-loaded engineering day rate, and to schedule using the proportion of that work on the integration critical path.
That low-coupling modules in your organization are a fair counterfactual for what high-coupling modules would cost if re-partitioned. This is an estimate of attainable improvement, not a claim that all excess effort disappears. Section 07 tests how much the conclusion depends on it.
06Worked example
The figures below are constructed to demonstrate the arithmetic. They are not a client result, not an average, and not a claim about what your program would show. No real engagement is described anywhere in this document.
Program profile
| Scope | 18 modules · 240 documented interfaces |
| Engineering effort on change, trailing 12 months | 1,200 engineering days |
| Fully-loaded day rate (assumed) | $650 |
| Integration cycles per year | 4 |
Measurement result
Coupling is concentrated: 4 of 18 modules (22%) account for 62% of cross-boundary interfaces, and three of the four sit on the integration critical path. Those four modules absorbed 71% of change effort in the trailing year.
Figure 1 — Change effort distribution. 22% of modules absorb 71% of effort.
Coupling multiplier
Normalizing for change size, work in Cluster A cost 2.4× the effort of comparable work in the low-coupling modules. Excess effort is the portion above that baseline:
Schedule translation
Three of the four modules sit on the integration critical path, carrying 68% of the excess — roughly 338 days per year, distributed across four integration cycles. At the observed parallelism, that is approximately 5.5 weeks of integration schedule per year spent absorbing coupling rather than delivering capability.
07Sensitivity
A single figure implies a precision the method does not have. The deliverable always presents a band, and names the assumption the answer is most sensitive to.
| Assumption | Range tested | Exposure | Influence |
|---|---|---|---|
| Coupling multiplier | 1.9 – 2.9 | $262k – $363k | Dominant |
| Attributable share of effort | 64% – 76% | $291k – $345k | Moderate |
| Fully-loaded day rate | $580 – $720 | $288k – $358k | Linear, low uncertainty |
| Attainable improvement | 50% – 85% of excess | $162k – $275k recoverable | Dominant on the return side |
Exposure lands between $262k and $363k per year, and the width is driven almost entirely by the coupling multiplier. If your organization measures change effort per module with reasonable fidelity, that band narrows sharply. If it does not, the honest answer is a wide band — and the first recommendation is usually to start measuring, because the uncertainty is itself a finding.
08Prioritization
The remediation portfolio is ranked by return, not by severity. A severe problem in a module nobody changes is not worth funding, and saying so is part of the deliverable.
| Candidate | Excess addressed | Est. effort | Payback | Call |
|---|---|---|---|---|
| Re-partition A│B boundary | 41% | 60 days | 0.45 yr | Fund first |
| Extract shared state, module C | 23% | 45 days | 0.60 yr | Fund |
| Interface contract, C│D | 14% | 30 days | 0.66 yr | Fund if capacity |
| Consolidate module F internals | 6% | 55 days | 2.8 yr | Do not fund |
In this illustration the top three address 78% of the excess for 135 engineering days, paying back inside eight months. The fourth is exactly the kind of work that gets funded on the basis of engineering discomfort and should not be.
09Limits — stated plainly
Every method has a boundary. These are the ones that matter, and they are raised at scoping rather than discovered at readout.
- Generalization of the validation. The classifier was validated on documentation from complex engineering programs. Its reliability on materially different corpora — consumer web codebases, data platforms, systems with negligible interface documentation — has not been established at the same level, and will not be claimed.
- The economic model is not the classifier. κ 0.84 describes classification reproducibility. It says nothing about the accuracy of the exposure estimate, which rests on assumptions in section 07 and is expressed as a band for that reason.
- Correlation, causal argument, not proof. High-coupling modules cost more per unit of change. That coupling is the cause rather than a correlate of some third factor — domain complexity, team experience, requirement volatility — is an argument supported by the counterfactual in section 05, not a controlled experiment.
- Documentation fidelity bounds the result. If interface documentation is materially out of step with the implementation, the coupling map reflects the documented architecture rather than the real one. Where source access is available this is checked directly; where it is not, the risk is stated in the deliverable.
- Point in time. The assessment describes the system as it is when measured. Coupling accumulates continuously; a figure more than two or three integration cycles old should be treated as indicative.
- Not a substitute for certification evidence. Where a program certifies to DO-178C, AS9100, MIL-STD-882, ISO 26262 or IEC 62304, this assessment scores against those obligations. It is not accredited by any of them and does not replace a DER, auditor or safety assessor.
10How your material is handled
- Scope, transfer method, retention period and destruction date are agreed in writing before any material moves.
- Handling constraints for controlled, classified or customer-proprietary material are confirmed at scoping, not assumed.
- Client material is never retained for benchmarking, used to train or tune any model, or referenced in another engagement.
- Where transfer is impractical, the assessment can be scoped so material never leaves your environment.
- Destruction is confirmed in writing on the agreed date.
Full detail in the privacy notice.