Definitely this! All systems are produced in a given context. The organisation and the people producing it are what matters most to get something of quality (or not).

Definitely this. It's a good reminder of the boy scout rule. It's fine to clean up as you go and when you find the opportunity.

If you're not recklessly accumulating technical debt, this is an interesting way to frame the conversation around it.

There are indeed way to deal with important but lower priority tasks. You want to tackle those to avoid your teams to slow down too dramatically.

It will fluctuate with time so it needs to be kept in check. Indeed, some things are commodities so can be decided upfront, but the rest of the functional envelope will change over time. Also make sure you drive the project by risks to have early feedback where it matters most.

Definitely this, too often I see projects treating the technical debt as one-off large tasks. Really it's something you should deal with bite sized and over time.

Makes sense, the "boyscout rule" has a psychology impact as well.

I'm not sure the incentives are right... it's better to clean up as you go. Still some places would benefit from such an event from time to time and even if you clean up as you go missed opportunities happen.

A bit of a high level view on technical debt. There's a couple of interesting insights though. In particular the lack of good metrics to evaluate technical debt... and the fact that it's probably about "both the present state and the possible state" of the code base. So it's very much linked to the human cognition in order to conceive the "ideal state".

Good approach for tackling it indeed. The crux of the issue is really measuring the tech debt since it's still a fuzzy concept and we have no good metrics for it.

This is indeed a more complex topic than it sounds. When someone complains about "technical debt" always inquire what it really means to them, what this is about, what are the symptoms.

I'd take the more stack related side of this article with a pinch of salt. It seems a bit too specific to the company behind the story. The rest of the article rings true and spot on though.

More thinking gets around the debate about tech debt. This is definitely welcome. Using more precise labels can indeed being clarity in conversations.

Good piece about the hype cycles our industry constantly fall into. So much undue complexity for nothing in some projects... and then we'll complain about technical debt. It would have been much easier to pick the right tool instead of wanting to use whatever new got released by some big tech company.

Interesting points in this article. The exact definition doesn't matter much. What really matters is the common understanding within a team of what technical debt is. It's also a good idea to be able to link it to actual money and business impacts.

Nice short post listing the main positions (and linking to corresponding articles) on the debate around technical debt. Worth mulling over all those.

Technical debt was an interesting metaphor to kickstart the conversation but has been overused. It can still be useful, especially with the proposed approach here to make it intentional and explicit. This can be factored in how to drive the project.

Definitely this. I think this could have turned into a good term until it was used for everything under the sun. It's about maintainability first, not just about what you like or not.

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.