> My code traded the ability to change requirements for reduced duplication, and it was not a good trade. For example, we later needed many special cases and be

> My code traded the ability to change requirements for reduced duplication, and it was not a good trade. For example, we later needed many special cases and behaviors for different handles on different shapes. My abstraction would have to become several times more convoluted to afford that, whereas with the original “messy” version such changes stayed easy as cake Yeah code duplication is fine when the commonality of code is incidental. The thing that bothers me is starting from the assumption that the requirements for each shapes are going to diverge. It looks like the wrong kind of premature optimization to me. In this case the refactoring seemed sensible, and unless they already _knew_ that this would happen soon, I think it was safe to assume that it wouldn't and that factorizing made sense. _Then_ duplicate the code in the future if it's necessary - seeing that the abstractions were not working properly. There are tons of codebases in the wild with large portions of duplicated logic, from experience they seem the rule rather than the exception for any sizeable project. "DRY" as itself is not a rule, but I think it makes sense to be doubtful of duplication as a default stance.