Isn't that what tech debt is about? You write code that works right now, but you know it should be refactored because of long term costs. Keep track of it, put

Isn't that what tech debt is about? You write code that works right now, but you know it should be refactored because of long term costs. Keep track of it, put it on a wall, quantify it (days, story points, whatever) and talk to your manager about what tech debts need immediate resolving, what are the nice to haves. The worst thing you can do is to build up tech debt and be silent about it. Tech debt needs to be handled, or else your software won't be maintainable in the long term and new features will cost much more and put the system in risk even more. And there is a nice slide about it: https://www.slideshare.net/cairolali/resolving-technical-debt-in-software-architecture/3 https://www.slideshare.net/cairolali/resolving-technical-deb... (In case you are wondering, the circle means, you're past any maintainability. Go to start, rewrite. If your client or manager wants to avoid it, he/she should plan for refactoring).