The age-old semantics discussion around how to handle refactorings. > The thing is, those bugaboos rarely intersect with the code’s most pressing maintenance c

The age-old semantics discussion around how to handle refactorings. > The thing is, those bugaboos rarely intersect with the code’s most pressing maintenance challenges. So when each engineer finishes their gang-of-four-fueled refactoring bender, the code is no easier to work in than it was before: it’s just different This gets rehashed a lot in various forms that amount to "there is no right or wrong way of doing something as long as it works, it's all just personal preferences". While I agree there are many ways to do something, you sometimes (not even rarely) cross paths with hot piles of untested tightly coupled unscalable non-monitored non commented convenience-biased nonsensical garbage, that are obviously wrong. > In all seriousness, this is a huge reason that spending three weeks paying down tech debt, carte blanche, often does little or nothing for the team’s velocity after those weeks have ended. I think what's meant there is that refactoring for the sake of refactoring is pointless, which I couldn't agree more. What I don't agree with is that this is an argument for discarding the notion of technical debt. A strategy I found more efficient in that line is to tackle it while building features. Rather than playing alongside or worse, around the idiosyncrasies of something broken, fix it. > we can track what specific elements of the system force feature development to take longer, measure them in terms of the amount of developer effort that they require On paper, sounds like a great idea, but also like a lotbof bureaucracy added to a team who ironically probably already feels a lot of pressure because of said technical challenges. The other thing is that, it's rarely clear-cut, you rarely have entire tasks you wouldn't have done because of debt, rather it's just taking longer because of that debt. You're still left with estimating the refactored side Overall what I take of the article is that the main point is not doing refactoring for its own sake. I don't actually gey the argument for why the term tech debt should not be used