From what I've seen, there are three big schools with technical debt (past choices that now make changes difficult): 1) Ignore it and gradually ossify as the c

From what I've seen, there are three big schools with technical debt (past choices that now make changes difficult): 1) Ignore it and gradually ossify as the code congeals and it becomes harder and harder to make any change at all. 2) Assign a fixed budget of time, e.g. 20%, to refactoring and bugfixing and updating models and "moving to the new version of the language/library which lets us ...". 3) Prioritise the engineering tidy-ups alongside features. This involves (a) being able to credibly estimate the effort and value in the same dimensions as feature work is estimated and prioritised; (b) the people who do the prioritisation believing that engineering-desired work is as necessary as sales-desired or PM-desired work. That last route requires people's beliefs and abilities to align. The middle route bypasses the entire prioritisation conflict at the cost of sometimes working too much or too little on technical debt. I think that's why you see a lot of fixed budgets for internal work.