I don't see technical debt as a problem, I see the lack of refactoring as part of a software teams culture as a problem. Technical debt will be incurred, if yo

I don't see technical debt as a problem, I see the lack of refactoring as part of a software teams culture as a problem. Technical debt will be incurred, if you like it or not. Even if you spend a long time on architecture and abstractions, developing software is a process and the "fantastic" architecture you created a year ago is now hopelessly outdated. This happens because over time your insight into the problem domain increases which will give you a better understanding on how to approach the problem which will lead to better decisions on all sorts of things regarding the software you're writing. Having refactoring as part of a software development team culture can help you manage technical debt. If you assume that the code itself isn't precious but the experience of the developers writing the code is, then you can move forward. You can have refactor sessions at regular intervals, e.g. every Friday afternoon or a whole Friday every fortnight, whatever works for you and your team. In a refactor session the whole team can work together to make the software better; many eyes make all bugs shallow [1]. It also give an opportunity to create better synergy and banter between team members. [1] https://en.wikipedia.org/wiki/Linus%27s_Law https://en.wikipedia.org/wiki/Linus%27s_Law