What Is DAX Tech Debt?
The model works. Every visual shows the right number, the refresh completes, nobody is complaining. And yet: every change takes three times longer than it should, the new developer is still lost after a month, and there’s one measure everyone has silently agreed never to touch.
That gap between works today and cheap to change tomorrow is tech debt. DAX tech debt is the accumulated cost of shortcuts and unexamined decisions in a Power BI model. Things like duplicated logic, unplanned dependency chains, dead objects, opaque naming, and missing documentation. And tech debt is paid as interest every time someone has to change or understand the model. The numbers can be perfectly correct while the debt quietly compounds underneath them.
Debt is a trade, not an insult
The borrowing metaphor deserves to be applied honestly, because “tech debt” gets thrown around as a synonym for bad work, and that’s not what it is. Debt is a loan: you get something now, something like the measure shipped in time for Friday’s meeting but and you pay for it later, in future change-cost. Taking that loan is often the rational call. The report that ships with a copy-pasted measure beats the perfect report that misses the decision it was built for.
The problem isn’t borrowing. It’s that Power BI models pay interest forever and nobody tracks the principal. The Friday shortcut never gets revisited; six months later there are four Friday shortcuts stacked on each other; and the interest, gets paid invisibly, out of everyone’s time, with no ledger anywhere.
The five forms of DAX tech debt
Debt in a model is not one thing. It takes five distinguishable forms, and they respond to different treatments:
1. Duplicated logic. Three near-identical “total sales” measures, created because nobody could find the original. Each copy starts identical and drifts with every small edit, until two visuals disagree about revenue and the model has lost the one thing it exists to provide: a single version of the truth.
2. Unplanned depth. Measure-on-measure chains nobody designed, running through measures nobody realized were foundational. Shared base measures are good architecture; ten accidental layers where every edit has an unknown blast radius is debt. The line between the two, and how to move a model across it, is the subject of reducing DAX complexity.
3. Dead weight. Unused measures, abandoned experiments, “temp” columns that shipped. This is the purest debt form: all interest, no principal. The objects deliver nothing, yet every maintainer must still read, consider, and rule out each one.
4. Opaque naming. Measure 7, Sales v2 FINAL, a 40-line expression with no comment. Opacity multiplies every other form of debt, because it converts each encounter with the model into a decoding exercise.
5. Missing documentation. No record of what tables mean, why relationships are shaped the way they are, or what a measure is for in business terms. The knowledge exists only in heads and some times heads leave the group or the company.
Interest and principal
The loan metaphor pays off in one distinction. Interest is what the debt costs you passively: the change that took a day instead of an hour, the onboarding that took a month instead of a week, the workaround built around a measure because changing it felt too dangerous. Principal is the debt itself meaning the duplication, the chains, the dead objects. Paying it down means the deliberate cleanup work that removes the cause rather than absorbing the cost.
Here’s the mechanism that makes unmanaged debt compound: interest causes more borrowing. When the model is scary, developers route around it. They do one more copy-pasted measure instead of touching the shared one, one more layer on the chain instead of refactoring it. Fear of the debt creates debt. That feedback loop, more than any single shortcut, is how a merely messy model becomes an untouchable one.
Making the debt visible
You cannot manage a loan with no statement. The single highest-leverage move against tech debt is a debt register: a short, honest list of what’s wrong with the model with each entry naming the problem, where it lives, roughly what it costs to fix, and what interest it’s charging in the meantime. Not a plan to fix everything; a ledger that makes the trade-offs explicit, so “we’ll clean it up someday” becomes “we’re consciously deferring these six items, and here’s what that costs us.”
The good news is that most of the debt is detectable. Three of the five forms are structural — duplication, unplanned depth, and dead weight are all encoded in the model itself, which means they can be found by scanning it rather than by intuition. DAX Prism surfaces exactly these: the dependency trees that expose accidental foundations and depth, and the unused-object detection that inventories the dead weight. The remaining two forms, naming and documentation, need human eyes, but they’re also the cheapest to fix as you go.
Debt you built vs. debt you inherited
One last distinction. Debt in a model you built is at least known debt. It might take a little to job your memory but you will remember the Friday shortcut, even if you never wrote it down. Debt in a model you inherited is undocumented debt: the shortcuts are invisible, the interest is unexplained, and the register has to be reconstructed from the artifacts alone. That reconstruction is precisely what a structured audit of an inherited report produces. Its final step is, in effect, writing the previous owner’s debt register for them.
Either way, the discipline is the same: name the debt, price it, and choose deliberately what to pay down and what to keep borrowing. Debt you’ve chosen is a strategy. Debt you haven’t noticed is just decay.