What I meant is, I've heard this kind of language from non-engineers before (mostly PMs) trying to get developers to ship something in a bad state. Most probabl

What I meant is, I've heard this kind of language from non-engineers before (mostly PMs) trying to get developers to ship something in a bad state. Most probably because they'll be gone before they start having to deal with the repercussions of the technical debt. >Limiting the amount of review iterations in a unit of work Fully agree. I think there should only be two iterations max, preferably just one. >splitting feedback-related work into other tickets Would never work at places I've worked. The backlog of "important tasks" is never-ending so code cleanups, optimizations, etc. never get done because there is always higher priority work. This isn't really in control of the team because even if the PM agrees to let you lose a week of productivity making the code better without adding features there's a good chance their manager, the engineering director, etc. won't like to see that. So at least in my experience you only have one shot at getting that code in a good state, with the alternative being the code slowly getting worse and worse until it gets so bad you opt for a rewrite or lengthy refactor