3. You write another duplicate of #1, so you should refactor. But the PM doesn't understand why you're changing the code you made in #1 and #2 as part of ticket #3.
So the jaded devs are certain the duplication will occur, but believe their choice is either to pre-emptively fix the duplication at #1, or never to fix it at all.
> But the PM doesn't understand why you're changing the code you made
If that is the case, the PM does not understand red-green-refactor, always-refactoring, or even just plain refactoring. I'd say the PM doesn't even understand the idea of technical debt, in that case.
The problem is certainly the PM's disconnect to how to keep a codebase (and their team) sane in the most common programming practices. And not the refactoring itself.
I agree with that assessment on the surface. But it's a sign of a generally unhealthy team, not just a poor PM (although the poor PM might be the root cause).
As c2 wiki has it[1]
> * The first time you do something, you just do it.
> * The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway.[...]
> * The third time you do something similar, you refactor.
E.g. I've seen a lot of Incidental Duplication being refactored out, leaving the code apparently cleaner, but in practice, really much worse.
[1] http://wiki.c2.com/?ThreeStrikesAndYouRefactor