Working in a team where the policy is "never left any tech debt behind" it is surprising the amount of tech debt we already have accumulated. In fact, you can argue that what we are cleaning is not tech debt, but cruft code, I agree.
For the shake of this conversation, we are going to assume that such code is impossible to avoid entirely. So, if we always clean it before closing a user story, how can we have any of it.
Some of it is structural, decisions that have been made without taking the whole picture in mind, or inconsistencies between different parts of the code. The main suspect a lack of shared knowledge in a team where nobody being the glue.
The big part, however, is a consistent and deliberate application of YAGNI principle or at least a version of it. Fix cruft code and decisions is postponed because we are not sure about the implementation, the design or a mix of both.
A wrong interpretation from my point of view, YAGNI and make easy to change code must be complementary. What do you think?
References:
@cammerman -> twitter.com/cammerman/status/1511936610765619200 @kentbeck -> tidyfirst.substack.com/p/incentives-not-to-invest-in-structure