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.

> Knowing when two things are one thing or one thing is two things is most of our job, right?

Yes, but often we don't know the domain enough but "this feature must be available yesterday". So add tests, copy, release. And when you have to either do it again or have to update this code and its original you should know more and be able to refactor and give good names to everything.