In my experience in avionics software development, the creation of software is driven by approved requirements. As requirements change or are refined, the software is updated to be consistent with those requirements. One type of “debt” I see is when functionality is not completed on time, and gets deferred to a later software release (cost increase). Another type is when a problem is found (requirements, source code, tests, documents), but addressing the problem is deferred to a future time (the problem does not impact the functionality of the requirements, source code, or tests, or is deemed not  a safety issue). This type of debt (typically called “open problem reports” (OPRs) is getting more scrutiny by aircraft certification agencies and OEMs (Bombardier, Boeing, etc.), since they see increasing numbers of OPRs as an indicator that the overall “health” of the software may not be as good as it should be, and that there should be as few OPRs as possible (in other words, fix your problems as you find them).

For myself, I prefer to fix problems when they come up. However, when you work as a member of a team, sometimes business decisions dictate otherwise….