How do I tell dangerous technical debt from code that is just ugly?

Most debt is not worth paying down

Developers frequently want to rewrite code because it offends them. That is a legitimate feeling and a bad basis for spending money. Code that is ugly, isolated, rarely changed and working is fine. It has been paying rent for years.

The question a business owner should ask is not whether the code is good. It is what happens when this code is wrong, and how hard it is to change when the business changes.

Three tests that separate the two

• The blast radius test. If this code misbehaves, does it produce a wrong screen or a wrong database? Wrong screens are recoverable. Silently wrong stored data is not, because by the time you notice, months of records are affected.
• The change-cost test. Ask for a small, well-understood change and watch what happens. If a one-line business rule change requires touching six files and manually retesting unrelated features, the structure is the debt.
• The bus factor test. If exactly one person can safely modify it, the debt is organizational rather than technical, and no amount of refactoring fixes it without documentation and a second set of hands.

The debt that hides in reporting

There is a specific category worth calling out because it rarely gets flagged: business logic duplicated across reports. The same definition of a booked job written slightly differently in four places.

Nothing crashes. The numbers just disagree, quietly, and leadership loses trust in all of them. This is a data-model problem masquerading as a reporting problem, and the fix is defining each metric once in a shared layer. It is one of the main reasons purpose-built reporting beats a pile of exported spreadsheets, and why revenue reporting has to be built on a single agreed definition.

How to prioritize when everything looks bad

Rank by expected damage rather than by disgust. Anything that can corrupt data goes first. Anything blocking a change the business needs this quarter goes second. Anything with a single point of human failure goes third — usually solved with documentation and a code walkthrough rather than a rewrite.

Everything else goes on a list and gets fixed opportunistically, whenever someone is already working in that file. Refactoring as a side effect of feature work is far more sustainable than a standalone cleanup project nobody can justify. If you are weighing a bigger intervention, the rebuild-versus-repair decision deserves its own analysis rather than being folded into a maintenance conversation.