[ahtihn]

Sometimes you just need to deliver quickly and cutting scope isn't an option.

Sure you can say that it's not possible. Then you get replaced by someone who's willing to take the necessary shortcuts.

What's important is to make it clear that you're taking shortcuts and that you will need time allocated to clean it up later. That's basically what technical debt is.

[wokwokwok]

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.

[drcongo]

This is still making a spectacular number of assumptions about other people's work environments. The technical debt they're dealing with may not even have been theirs in the first place, it could be an external codebase. It could be a dependency that's long since abandoned and is now a security risk. It could be that the project is deployed against a really old DB and the feature requested needs that upgrading. It could be any one of an almost infinite number of things that none of your scenarios seem to be aware of.