DRY is a terrible, terrible, principle because it’s correct but requires programmers to make this decision. Which they won’t because DRY has thought them that a

DRY is a terrible, terrible, principle because it’s correct but requires programmers to make this decision. Which they won’t because DRY has thought them that all duplication is bad. The flip-side is what you’re saying, where there are simply things it wouldn’t make sense to duplicate. I’m a strong advocate against basically every Clean Code principle, really anything, which isn’t YAGNI. That doesn’t mean I think you should create datetime services every time you need them. It doesn’t mean I don’t think you should make a “base” audit mixin/abstract when you want to add “created_at”… to your data model in your API. I think a better way to look at it than “third time - consider refactor” is to follow this article and ask “will this ever need to be extended?”. If the answer is yes, then you should duplicate it. This way you won’t get a flying dog in your OOP hellscape but you also won’t have to change your holiday service 9 million places when your shitty government decides to remove one of them (thanks Denmark). Between the two, I would personally prefer working on the one where I have to do the 9 million changes, but I would obviously prefer neither.