| Lots of people have fought with technical debt for a long time, and if it was as easy as just being like, 'oh hey, we just do it next sprint' it wouldn't be a thing. ...it's not that easy. It's not easy. I'm not saying it's easy. I'm saying: If you do the easy thing, which is always choosing to leave technical debt behind, and waiting for someone to come and tell you its ok to deal with it... you're going to have bad long term outcomes in your project. Part of your job, as an engineer / developer / whatever to spend a portion of your time not just doing work, but ensuring you can continue to deliver value in the future. Here's a metaphor for you: Some people like 'release based' branching; because you can push all your changes into develop (however messed up they are), and then some poor soul has to someone pull out a release candidate and then slave away over it to make sure it works... You release seldom... but, most developers don't have to worry about it (just the release manager), and its fine. Some people prefer trunk based development; it's harder. Every merge to master you have to make sure your code actually works, because hey, it might go live in the next 2 hours. A lot of people really hate this, because it means they have to do a lot of work and they cannot push the hard work onto someone else. ...do you see the metaphor? I think it's pretty relevant. Address technical debt slowly and continuously, not rarely and massively, and you will, in my opinion and experience, have better outcomes. |