The cost and price scale non linearly to the amount of change. So, waiting to refactor has an exponentially higher cost the longer you wait whereas doing lots of small refactoring as you go has a relatively low cost. To the point where it's just negligent not to do it. You can spend five or ten minutes cleaning up a little or you skip it. Not doing it is sloppy. Just apply the boy scout rule.
People have the wrong reflexes where being overly conservative and fearful to change a working system eventually leads to a system that becomes so hard to fix that people stop bothering to even try and just replace or retire it in the end. Which is very expensive and destructive of course. Usually such decisions become a reality when people leave or change teams and it turns out there's nobody around that even has a clue where to begin fixing the old thing. Getting rid of the thing then becomes the logical choice.
Calling it technical debt is a way of talking yourself into believing you can deal with it later. Quite often that doesn't work out that way. Another fallacy is believing the debt is something with a fixed/known price that you can pay off at the time of your choosing. You can't; it's literally risk that accumulates that you haven't properly analyzed and estimated yet. Some of it might be fixable, some of it might not be. You won't know for sure until you sit down and do the work. Deferring the process of finding out is what gets teams into trouble. The less you know what you can still fix the more likely it is that the cost has become stupendously high.
Half the work is just knowing what needs doing and how it needs to be done. That doesn't mean you do the work right away. But spending a lot of time chin stroking over stuff you could do without actually doing stuff (aka. analysis paralysis) is also not productive. Finding a balance between knowing what needs doing and then just balancing new stuff vs. making sure that the cost of that new stuff isn't overly burdened by broken old stuff is the name of the game. Having a lot of technical debt usually translates into work that ought to be quick, simple, and easy being anything but those things. So, the technical debt metaphor means that you burden the cost of future essential work with that extra burden. Until you fix it, it only gets worse and worse. You pay the interest on every change until you fix the problem. And you won't know how expensive that is until you do it.
That's why you should refactor a little bit all the time. Low cost, it lowers your risk, and it keeps you aware of all the pain points and weak points in your system.
Agreed. Refactoring is like cleaning your house. Spending ten minutes cleaning/organizing your place daily is much less painful than waiting until that one day a month and spending 3-4 hours doing it. At least for me, anyway.
People have the wrong reflexes where being overly conservative and fearful to change a working system eventually leads to a system that becomes so hard to fix that people stop bothering to even try and just replace or retire it in the end. Which is very expensive and destructive of course. Usually such decisions become a reality when people leave or change teams and it turns out there's nobody around that even has a clue where to begin fixing the old thing. Getting rid of the thing then becomes the logical choice.
Calling it technical debt is a way of talking yourself into believing you can deal with it later. Quite often that doesn't work out that way. Another fallacy is believing the debt is something with a fixed/known price that you can pay off at the time of your choosing. You can't; it's literally risk that accumulates that you haven't properly analyzed and estimated yet. Some of it might be fixable, some of it might not be. You won't know for sure until you sit down and do the work. Deferring the process of finding out is what gets teams into trouble. The less you know what you can still fix the more likely it is that the cost has become stupendously high.
Half the work is just knowing what needs doing and how it needs to be done. That doesn't mean you do the work right away. But spending a lot of time chin stroking over stuff you could do without actually doing stuff (aka. analysis paralysis) is also not productive. Finding a balance between knowing what needs doing and then just balancing new stuff vs. making sure that the cost of that new stuff isn't overly burdened by broken old stuff is the name of the game. Having a lot of technical debt usually translates into work that ought to be quick, simple, and easy being anything but those things. So, the technical debt metaphor means that you burden the cost of future essential work with that extra burden. Until you fix it, it only gets worse and worse. You pay the interest on every change until you fix the problem. And you won't know how expensive that is until you do it.
That's why you should refactor a little bit all the time. Low cost, it lowers your risk, and it keeps you aware of all the pain points and weak points in your system.