This. I think you’re hitting the nail on the head. The question is whether there are multiple dependencies on a given bit of code. When there are multiple depen

This. I think you’re hitting the nail on the head. The question is whether there are multiple dependencies on a given bit of code. When there are multiple dependencies, changing the code because one of them wants something means the code needs to be checked and tested against all the other places the code is being used. And it’s really really common to have inadequate understanding and inadequate test coverage, so things break, and hence people develop superstitions about code that shouldn’t be touched. Another way of putting it is that if the code is really truly duplicated, then it doesn’t need to change at all. If it has to change, the need for change is there because the multiple parties depending on that code have slightly different needs and slightly different ideas about what they want. Abstracting the code to make deduplication happen is just a way of spackling over those differences, but it can and does often cause trouble down the road, even when it’s done well. Once abstracted for two dependencies, a third dependency or more without test coverage can make changes exponentially more dangerous and error prone. Duplication is good when forking for separate parties (or separate dependencies), each of whom may wish to customize the code, and now they are free to do so without the risk or fear of breaking someone else. I feel like the author of the article didn’t understand the benefits of duplication.