What is logic debt?
Technical debt is the cost of choices that save time now and cost more later. The idea comes from Ward Cunningham, who in 1992 compared shipping not-quite-right code to taking on a loan: useful at first, but the interest builds every time someone has to work around it.
In a data warehouse, most of that debt is not in the tables. It is in the logic that turns raw data into the numbers the business trusts: stored procedures, ETL packages such as SSIS, BTEQ and Hive scripts, views, and the schedules that run them in the right order. We call this logic debt.
Logic debt grows quietly. A rule is added for one report and never removed. A procedure is copied and changed instead of fixed. A job keeps running long after its report was retired. Nobody sees the cost until the platform has to change, and then every one of those objects has to be read, moved and proven.
How big is technical debt, according to the research?
Several large studies have tried to put a number on it. Their methods differ, so their figures are not directly comparable, but they point the same way.
McKinsey surveyed CIOs in 2020. They estimated technical debt at 20 to 40 percent of the value of their entire technology estate, before depreciation. Sixty percent said their technical debt had risen noticeably over the previous three years.
Stripe and Harris Poll surveyed more than 1,000 developers and more than 1,000 C-level executives in the United States, the United Kingdom, France, Germany and Singapore in 2018. They found the average developer spends more than 17 hours a week on maintenance issues such as debugging and refactoring, and about 4 hours a week on “bad code”. Stripe estimated the opportunity cost of bad code at about $85 billion a year worldwide.
Gartner expects technical debt to shift toward architecture. Its May 2026 Magic Quadrant for Technical Debt Management Tools states that by 2027, 80% of technical debt will be architectural.
| Study | Who was asked | Key finding |
|---|---|---|
| McKinsey, “Tech debt: Reclaiming tech equity” (2020) | CIOs | Tech debt is 20 to 40 percent of the value of the technology estate before depreciation; 60 percent say it rose over three years |
| Stripe and Harris Poll, “The Developer Coefficient” (2018) | More than 1,000 developers and more than 1,000 C-level executives in five countries | More than 17 hours a week on maintenance; about 4 hours a week on bad code; about $85 billion a year in opportunity cost |
| Gartner, Magic Quadrant for Technical Debt Management Tools (May 2026) | Analyst assessment | By 2027, 80% of technical debt will be architectural |
| Sculley and others, Google, NeurIPS (2015) | Engineers’ analysis of production systems | Data dependencies cost more than code dependencies; pipelines and dead code paths build hidden debt |
Why do data systems collect debt faster than application code?
Engineers at Google answered this in a 2015 paper, “Hidden Technical Debt in Machine Learning Systems”. Their subject was machine learning, but most of what they describe is about data, and it fits legacy warehouses closely.
Their central point is that data dependencies cost more than code dependencies. A compiler can tell you which functions call which. Few tools can tell you which jobs read which tables, which reports use a column, or what breaks if a feed changes. The dependencies exist, but nobody can see them.
- Pipeline jungles
- Data preparation grows into tangled chains of scripts, joins and intermediate tables that are hard to test or change. In a warehouse these are the nested procedures and staging jobs.
- Dead code paths
- Old branches stay in production long after anyone uses them. The paper cites Knight Capital, which lost $465 million in 45 minutes, apparently because of obsolete code paths.
- Undeclared consumers
- Outputs are read by systems nobody listed. Changing them is, in the paper’s words, “expensive at best and dangerous at worst”.
- Configuration debt
- Settings can outgrow the code itself, and each line is a chance for error. In a warehouse, this is the scheduler configuration and the parameters scattered across jobs.
- Glue code
- Large amounts of code exist only to connect one system to another, and lock in old assumptions.
- Entanglement
- Inputs interact, so “changing anything changes everything”. Fixing one rule can change numbers elsewhere.
Where does logic debt hide in a legacy warehouse?
In the places a migration has to touch. The table maps each kind of object to the debt it usually carries and how to find it.
| Object | Typical debt | How to find it |
|---|---|---|
| Stored procedures | Cursors, dynamic SQL and nested calls that encode business rules nobody wrote down | Parse every procedure and band it by complexity |
| ETL packages (SSIS) | Control flow, script tasks and data flows that call procedures | Parse the package with the procedures it calls |
| Scripts (BTEQ, Hive) | Branching and error handling inside the script, outside the SQL | Parse the control commands, not only the SQL |
| Views | Layers of views on views, some no longer used | Map lineage from source table to report |
| Schedules | Ordering rules and dependencies held in the scheduler | Export the scheduler and link each job to its objects |
| Dead code | Objects with no caller, no schedule and no reads | Check callers, schedules and query history together |
| Undocumented consumers | Reports, extracts and applications that read warehouse tables | Check query logs and ask each domain owner |
Why does logic debt set the cost of a migration?
Because moving data is a solved problem and moving logic is not. Copying tables to a new platform is mostly mechanical. Every procedure, package and schedule, on the other hand, has to be read, converted and proven to give the same numbers.
That makes the count of objects, and how complex they are, the best predictor of migration effort. Terabytes mostly decide how long the data copy and the reconciliation runs take. They say little about how much work the logic needs.
It also explains why migration budgets overrun. A price set before anyone counts the logic is an estimate. When the procedures, packages and dead code turn up during the project, the estimate moves.
How should a team measure logic debt before a migration?
With an inventory that comes from the code itself, not from memory. Five measurements cover most of it.
- Object count by type: procedures, functions, views, packages, scripts and jobs, each counted once.
- Dead code: objects with no caller, no schedule and no reads, listed with the evidence and confirmed by each domain owner.
- Complexity band per object: low, medium or high, based on cursors, dynamic SQL, nested control flow, temporary tables and error handling.
- Lineage: what each object reads and writes, so the estate can be moved one self-contained domain at a time.
- Coverage: for each object, whether a tool converts it by rule, whether it needs an engineer, or whether it is not covered at all.
Novuz runs this inventory as its $3,000 estate assessment, in three business days, and fixes the migration price from it. We mention it so readers can weigh this note; the five measurements work with any tool or team.
What are the limits of this note?
The studies above measure technical debt in general, across many kinds of software. None of them isolates data warehouse logic, and we know of no public study that does. The figures show the scale of the problem, not the size of any one estate.
The surveys rely on what CIOs and developers report. The Google paper is an engineering analysis, not a survey. Readers should treat the numbers as directional and measure their own estate before drawing conclusions.
Sources
- McKinsey & Company, “Tech debt: Reclaiming tech equity”, 6 October 2020
- Stripe and Harris Poll, “The Developer Coefficient”, September 2018
- Sculley, D., Holt, G., Golovin, D. and others (Google), “Hidden Technical Debt in Machine Learning Systems”, Advances in Neural Information Processing Systems 28 (NeurIPS 2015)
- Gartner, Magic Quadrant for Technical Debt Management Tools, May 2026: by 2027, 80% of technical debt will be architectural
- Cunningham, W., “The WyCash Portfolio Management System”, OOPSLA 1992 experience report (origin of the technical debt metaphor)