I’d search hackernews and read the top 10 submissions, I’m sure you’ll find something useful: Hacker News Search powered by Algolia
From glancing at the search result, Martin Fowler seems like a good source, he also links to two other articles of his on technical debt.
I think it’s mostly about explaining to people why a certain debt has been slowing you down (or why you expect that it will slow you down for upcoming task X) and how you are addressing it so future development will be faster again.
Edit:
I share the view expressed in this article that technical debt is to be expected in almost any project and that it only makes sense to work on it if it slows you down:
You can have areas of your application that have significant portions of technical debt for years and still not actually negatively harm the business or product. This is simply because those areas don’t change often, and therefore don’t actually harm development against them. This is why in large companies you often see services with older language code that has been untouched for years.
Fowler considers taking up technical debt often not even worth in the first place in his Design Stamina Hypothesis article.
When your delivery is above the design payoff line neglecting design always makes you ship later. In technical debt terms it’s like taking out a loan but not using the principal for so long that by the time you use it you’ve paid out more in interest payments.
This raises the question of where that line is. […] I take the view that it’s much lower than most people think: usually weeks not months. But again this can only be a judgment call.
For me this goes too much into the direction of predicting the future and future requirements, which, like measuring productivity, we can’t reliably do. YAGNI and all that. But it will always be a judgment call. Some design decisions obviously have more weight to them than others. (see Data Structures in the article by Shaun McCormick)
I’m also reminded of this quote from Kent Beck’s book Refactoring:
In almost all cases, I’m opposed to setting aside time for refactoring. In my view refactoring is not an activity you set aside time to do. Refactoring is something you do all the time in little bursts. You don’t decide to refactor, you refactor because you want to do something else, and refactoring helps you do that other thing.
While fixing a flawed design might not be possible to do in small incremental steps, I think working on technical debt should always serve the clear goal of making certain future changes easier.