Excellent piece about technical debt. The approach proposed is definitely the good one, it's the only thing which I know to work to keep technical debt at bay.

Interesting points about complexity. Indeed it's everywhere the problem is when you start to silently (and unwillingly) worship it... coupled with fear of changes this can only lead to piling more and more complexity in your systems.

Very interesting musing about the technical terms we often use wrongly and how it difficult it is to be understood.

Good reminder of why "tech debt" is not a so bright metaphor. I find it useful sometimes but clearly it became overused in the industry (often a sign of something loosing its meaning whatever it was). That's why lately I'm talking about complexity, some of it being legitimate so you need to keep the illegitimate one at bay. I like the focus on maintenance in that post. Also there are a couple of good ideas on how to schedule the maintenance tasks in your project.

Interesting use of mob/ensemble programming to tackle technical debt on projects.